Le 17. 11. 14 14:41, Paul H a écrit :
--------------------------------------------
On Mon, 17/11/14, Jean-Christian de Rivaz <[email protected]> wrote:
If you take the risk to rely exclusively on a vendor BSP, take your
responsibility and don't blame others for your poor choice. Most today SoC
vendors understand that there must upload there patches to mainline
Keep in mind that the individual you are addressing may not even be from the company who
made the SoC choice, let alone be the person responsible. In my case for example, one of the
targets I support is a niche-market, low-volume, integrated system built by a 3rd-party
where the SoC has been "accidentally" included into a system because it happened
to be attached to the one-of-a-kind hardware which made the system viable in the first
place. No doubt their engineers chose diligently for power consumption, environmental
ratings, board layout constraints and supply chain availability but as the SoC makes up
<1% of the design effort I'd say mainline linux kernel support somehow slipped their
initial selection criteria.
If the SoC vendor have a Linux kernel BSP you have access to the source
code by the Linux kernel license definition. From this point either the
SoC vendor do the upstream submissions to the mainline kernel as it
should do, either you have to maintain yourself there port by rebasing
it on top of the mainline kernel. I have experienced the second
situation many years ago back to the days Linux was something new to
many SoC vendors and yes this is painful. AFAIK most SoC vendors play
now the game fairly well, but I agree that this don't exclude that a few
of them still play a bad game. That said, a few bad players are unlikely
to change the evolution of the mainline Linux or of Debian.
kernel and do it routinely. This means that while some vendors still offer
BSP (because there have clients asking for it), last mainline kernel run as
well just fine on there SoC.
But this is only very recently the case, no? TI for example only *just* finally
achieved mainline kernel support for a few SoC models in the Sitara family
beginning 8 months ago. They are shipping a lot more SoC variants stuck on
kernel 2.6, 3.0 and 3.2 than they have in mainline.
I have used TI SoC with mainline kernel even before some OMAP2 SoC was
renamed Sitara. This sometimes require a few patches, but I don't
remember that was so hard. Usually old SoC are pretty well supported by
mainline kernel because over time his community get bigger. The issue is
more problematic for very new SoC with still only a small initial community.
"ARM CPU architecture support" != "SoC" support. I have personally tried to
port our SoC vendor's crappy 3.0 kernel up as far as I can; I can get as far as kernel 3.5 where
its proprietarity peripheral bus' magic, undocumented timing/DMA/interrupt quirks really start to
fall apart (I do not have deep enough knowledge of the chip or these parts of the Linux kernel to
complete the work in a timely manner).
If you hit this kind of problem, then you must ask support from the SoC
vendor to help you using there product. I suggest to start with the
mainline kernel and see if there is features missing for your
application. Then get in touch with the SoC vendor kernel hackers to
find a solution for you needs. This is really a SoC vendor issue, not a
Debian issue. Kernel / SoC interaction can require very deep knowledge
on the chip internal architecture and this knowledge source is on the
SoC vendor side only.
Regards,
JCdR
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
