[Buildroot] [RFC] ti-gfx: add new package
Yann E. MORIN
yann.morin.1998 at free.fr
Fri Jun 14 23:12:30 UTC 2013
Charles, All,
On 2013-06-14 13:58 -0700, Charles Krinke spake thusly:
> Behind my comments is the issue of TI's practices and I hope we dont
> make it worse by tweaking buildroot in an unusual direction, but I
> will, as usual, follow your lead.
Hmm. I guess we *do* want to hear opinions like yours. That's what in
the end shapes what Buildroot is, and where it goes.
Then, any enhancement should be done in a way that follows the Buildroot
"philosophy" (which is rather not-so-well defined, although the great
lines revolves around KISS, basically, and easiness for the user).
> My perspective is from working with the TI AM3517_evm for the last
> year.
Getting input from people that have experience on the topic is very good
to have. Thank you! :-)
> One of the issues is the fact that TI supplies their kernel
> source out-of-tree as a distribution release. As a consequence no one
> cannot expect kernel.org kernels to work properly for at least this
> reference design.
There has never been such expectation expressed.
Also, we already have some defconfig for some boards where the kernel is
not retrieved from k.org, but from a third-party. For example, the
RaspberryPi defconfig points to the github clone/fork that has RPi
support, and not to k.org.
I can't see a reason not to provide such a defconfig for other boards.
Unless it is no possible to easily retrieve the kernel from that TI
packaging /mess/.
> That is, the TI kernel modifications never made it
> into the mainline kernel, so we have a non-kernel.org situation to
> start with. This should cause buildroot to tread carefully unless we
> also get the patches from TI that change a standard kernel into a
> TI-special kernel.
There is no way Buildroot carries such patches, indeed. Either the user
starts up with the defconfig, or is versed enough to point Buildroot to
use a TI-ready kernel.
> On the Graphics_SDK, since this is a product that TI releases along
> with their kernel from time-to-time. Since this is also not an
> opensource project, I have some angst with patching the released
> Graphics_SDK. This doesnt make any sense to me since this product
> along with the kernel are releases from TI.
Buildroot has a very good infrastructure for declaring licensing
information per-package, and preparing a manifest of such licensing
terms for the user to *review* (and not trust blindly), and decide
whether the licenses combination is valid for him, in his jurisdiction,
for his use-case, and so on...
The Graphics_SDK will *not* be bundled in Buildroot; it's only the user's
actions that will trigger a download/build/install of the Graphics_SDK
source code and binary blobs to his rootfs.
> So, I guess the key issue is mixing distribution releases from a
> vendor with traditional, well-known opensource projects and how
> buildroot can best move forward.
Licensing infrastrucuture, my friend! :-)
make legal-info
Regards,
Yann E. MORIN
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list