[Dev] [ARM] Parabola ARM Port

Isaac David Reyes González isacdaavid at gmail.com
Mon Dec 15 08:14:23 GMT 2014

I'm excited to see real efforts for a wholly free ARM distro going on,
something higher than Debian I mean. There are far more ARM CPUs than x86
ones nowadays, and while not all of them will be able to work with free
software a substantial proportion will. Those ought to be covered. This is
an increasingly important computing platform dominated by GNU+Linux,
Android/Linux and other free-software-based operating systems; therefore
the success of ARM indirectly is the success of free software for the
masses too.

Ok, so here I will be trying to address some issues that I think went
overlooked before the thread forked:

>We need some research before packaging anything:
>- how archlinuxarm.org works (e.g. crossbuilding) and what we should use
>  from them?

Maybe everything that is already libre or can be repackaged to meet the
standards, as you do with normal Arch I guess. The big problem with ArchARM
is the myriad of kernels they support. See
https://bbs.archlinux.org/viewtopic.php?pid=1227684#p1227684 for a light
discussion on merging Arch with ArchARM, developers from both camps joined
and discussed kernel proliferation. I just counted 48 from ArchARM's [core]
repo but we may not need to support them all. The details can be found on
my attatchment and I hope this introductory research will help Parabola
decide what kernels to use (deblobbed) from ArchARM if any. I could add
this info somewhere in the wiki during the following days if you like it.
It would be nice to do the same for u-boot.

>- what devices we want to support: popular here, sufficiently free and
>  also something fast for building packages (some certainly don't
>  support cross-compiling and native builds are a good way of finding
>  bugs); will we compile packages for ARMv7 only?
>- what kernels will we use?  can we avoid deblobbing and releasing a
>  different kernel tree for each board?
>- u-boot trees; there are existing deblobbing projects for specific
>  boards
>- what's missing in the development tools that we used for mips64el?
Michał Masłowski clearly knows what he says. This is the way to go
>We should aim for compiling all packages

Even packages that don't need repackaging? Is this what you do with x86

>Do you know any fast multicore boards with much RAM and a SATA port that
>would work for native builds?  I think i.MX6 Quad and Tegra K1 are the
>fastest SoCs that work without known to me bootloader blobs (Samsung
>Exynos is not ok).

All in all Novena board is a good candidate: iMX6 Quadcore, 4 GiB in RAM,
works without nonfree software, in fact there's just a couple trivial blobs
keeping it from being FSF-endorseable at the time, no treacherous computing
of course and unlike many board developers the Novena people is working
hard to collaborate upstream and keep their software updated. Linaro was
interested in getting some Novenas and use them to build software natively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20141215/95984aa0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm2
Type: application/octet-stream
Size: 8183 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20141215/95984aa0/attachment.obj>

More information about the Dev mailing list