Le 17. 11. 14 14:41, Paul H a écrit :
-------------------------------------------- On Mon, 17/11/14, Jean-Christian de Rivaz <jc@eclis.ch> 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 mainlineKeep 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.
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.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.
"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