[Dev] [ARM] Parabola ARM Port

Paul Hanzlik pjhanzlik at openmailbox.org
Mon Dec 15 19:56:58 GMT 2014




-------- Original Message --------
From: Paul Hanzlik <pjhanzlik at openmailbox.org>
Sent: December 15, 2014 1:54:37 PM CST
To: ingegnue <ingegnue at riseup.net>
Subject: Re: [Dev] [ARM] Parabola ARM Port

Hi everyone, according to this link posted below the radxa rock pro looks like a good device to port Parabola onto.  Does anyone actually know how free that hardware is?

regards,
Paul Hanzlik

Source:  https://wiki.debian.org/FreedomBox/TargetedHardware

On December 15, 2014 10:19:22 AM CST, ingegnue <ingegnue at riseup.net> wrote:
>Ok, so from that Arch thread: "If the boards are not yet standardized
>enough that the kernel can be easily used across multiple boards (the
>great majority, really)"
>
>And this post, in full:
>https://bbs.archlinux.org/viewtopic.php?pid=1248427#p1248427
>
>With that in mind...
>
>FWIW if you search "gpl violations arm" you'll get a lot of results.
>For example, Allwinner, member of Linaro... I think there may be
>freedom issues that would narrow down what we would "officially"
>support.
>
>http://linux-sunxi.org/GPL_Violations
>^The above scared me away from Allwinner and made me look at Linaro
>skeptically.
>http://www.itworld.com/article/2741085/mobile/linux-arm-support--a-hot-mess--an-ugly-clean-up.html
>^That sounds ugly...
>
>As far as I see, GTA04, BeagleBone Black and Novena are easily the
>freest ARM systems I've found, so I would prioritize supporting them
>over, for example, anything with Allwinner in it (Cubieboard), if we
>have to choose between boards. I may get a BeagleBone myself and help
>with this port...  
>
>The nightmare scenario in my mind would be the ARM manufacturers
>sneaking in nonfree features to the kernel in those 70,000 lines of
>code per pull. But if we have the Linux-libre kernel, then maybe that
>possibility would be minimized, and more so if we avoid supporting the
>manufacturers that violate the GPL.
>
>Not an expert by any means, but I hope this info is of some use.
>
>
>
>On December 15, 2014 3:14:23 AM EST, "Isaac David Reyes González"
><isacdaavid at gmail.com> wrote:
>>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
>>Arch?
>>
>>>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.
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Dev mailing list
>>Dev at lists.parabola.nu
>>https://lists.parabola.nu/mailman/listinfo/dev
>
>_______________________________________________
>Dev mailing list
>Dev at lists.parabola.nu
>https://lists.parabola.nu/mailman/listinfo/dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20141215/497484a2/attachment.htm>


More information about the Dev mailing list