I’m still digging into CSI support for Dragonbard 845c for yocto build.
I just found codeaurora provides kernel msm-4.9, which supports CSI on 845c.
So I want to know, whether qualcomm maintains two versions of kernels ( codeaurora hosted version and linaro’s ), and why?
I did see the codeaurora version is more Android oriented, and linaro’s version is more “normal” linux oriented
hey,
the msm-4.9 kernel is mostly produced/maintained by Qualcomm. It is the baseline of what is being used by phone OEM when they make a phone with SDM845 for example. The overall rule is that Qualcomm supports 1 version of the kernel for each SoC they produce. They tend to pick the ‘latest’ LTS by the time they start working on that SoC, but then it’s not update in the life of the SoC. e.g. if your phone runs on 4.9, it will run on 4.9 forever.
There are more recent msm branches, such as msm-4.14, but that’s for newer SoC.
Qualcomm is a member of Linaro, and one of the thing that Linaro does as part of this membership/partnership is to work on enabling some of the Qualcomm SoC in the mainline kernel. The Linaro branch that you mentioned is produced/maintained by the overall open source community around Linux and Snapdragon. That’s mostly folks from Linaro and Codeaurora, though we are seeing contributions from others too.
The Linaro releases for DB845c offer an alternate choice, which is a regular/mainline Linux kernel , that is fairly recent. It’s much closer to vanilla Linux , that you would expect on any modern Linux system. One obvious difference between mainline and msm maintained trees is that some features are either missing or partial. But sometimes there are features in the upstream based releases that aren’t available downstream (OpenGL being one of them, using an open source GPU driver).
Users are free to pick/choose what’s best for them. If you want to contribute to our releases that’s very much possible! If you need/want more than what is being done ‘for free’ in the open, Linaro can provide additional resources (at cost) as well.
I hope it clarifies the working model a bit!
Thanks for your reply! It is clear to me.
Thanks again for your time.
Hi, I have additional questions.
Sorry to bother. I just want to make a decision: whether I should stick to linaro version with more recent code base just to make CSI to work, or I need to purchase their SDK to start to work on my project.
linaro version does have more recent code base, and I need them ( like more recent ROS2, rust, gstreamer 1.16, etc)
in contrast, LE OS version does has all components work, but other software features I need to add them myself ( Due to my failure to build Code Aurora version, I cannot ensure I can just add yocto compatible layers of ROS2, rust, or gstreamer )
In fact I have tried to build linux-msm-4.9 into recent linaro released manifests. It can boot but hangs during modprobe. And I saw some failure messages for CSI perhaps. I want to know whether it worths if I payed more time on it.
Thanks very much
PS. If need to pay for linaro to work on CSI feature, how much is it supposed to cost? We are only a tiny company, I’m afraid whether we can afford it.
PS. Whether I should use 820c instead of 845c? I see 820c has more mature drivers support
hey,
many questions… let me try to answer them.
Yes, the firmware release is ‘full’. There are features in the firmware that we aren’t using in the Linaro release. But there is no difference between the firmware release from Linaro and the one from Thundercom. In fact, the firmware release from Linaro is just the same , since we receive the firmware from Thundercomm, and publish them.
‘firmware’ for CSI is vague. in fact ‘firmware’ itself is vague. Can you please describe what you want to do with CSI? e.g. which image sensor do you want to use? what images features do you expect for your application (resolution, cropping, resize, …)?
For us, firmware typically means ‘some blob’ that does not run on the main application processor. e.g. GPU firmware runs on the GPU, DSP firmware runs on the hexagon, … A full camera use case requires (from a high level view) the following software component:
Some image sensors have integrate ISP, and deliver YUV images onto CSI, some don’t. Sometimes , th e camera application expects the RAW Bayer data, not the YUV… So we need to understand your use case.
Qualcomm kernel, e.g. msm-4.9, has full support for Camera. But in that case, they use a simple camera driver in the kernel, and have most of the camera features impletemented in some proprietary form in the user space. In theory, you should be able to pick the kernel patches from msm-4.9 that QCOM camera user space needs, and port that over to Linaro kernel, and get things to work there. But that means you have to deal with the proprietary user space libs/apps accordingly.
It’s a bit of a mess, it’s undeniable… We are planning to add CSI drivers support in the Linaro release (not in the very short term, probably a few months away from that), but you would only get RAW Bayer data (from RAW Bayer sensor), or YUV (if you are using a sensor with integrated ISP).
Great Thanks for your reply!
Shame to me for my inaccurate description.
Partially understand.
For Qualcomm Robotics RB3 Platform, it provides an OV8856 sensor as a main camera, it only provides RAW output, which should be your mentioned RAW Bayer data?
So after linaro supports CSI driver, it can interface with this sensor, but no ISP driver, application can only do preliminary processing in software manner instead of ISP provided by SoC?
And ISP drivers may be more proprietary and may not have that driver for linaro?
Basically I want to do a dual camera vision project.
So I need to connect two (whatever) cameras into the the board. For multiple purpose, I want (at least) one camera has 4K video output, the other camera can have lower resolution.
So for common OV5640, it can output YUV, so it will be sufficient to only has CSI and I2C interfaces available to Linaro release and application to access.
But for OV8856 provided in RB3 DevKit, which only provided RAW data, so it’d be better to have ISP support to convert RAW to YUV, optionally scaling, and transferred to application for further processing.
And both OV5640 and OV8856 has linux driver support in mainline source code. so it will not be issue.
However, if I choose other than sensors supported in mainline linux, then at least the sensor driver itself would be another thing need to concern.
Even if I can use msm-4.9 kernel to work on with, the user space driver provided by LE OS is “hard coded” OV8856 driver, then this would be another story if I reuse this architecture from Qualcomm Official release.
So to my requirement, there could be two options with sdm845:
stick to Linaro release, and for now using USB camera for testing / verifying our stack and algorithm and developing applications, waiting for CSI supported Linaro release, then choose one image sensor with ISP to replace USB camera.
stick to qualcomm/thundercomm provided platform image, purchase their commercial license to get full software build stack and add my required software stack onto it, then develop our solutions.
(Or 3. we purchase Qualcomm license to get full documentation and implement what we need by ourselves onto Linaro release / mainline kernel, besides its big work, will Qualcomm allow these implementation GPLed into linux kernel ( if no use Qualcomm proprietary code )? )
