All,
Dmitry has now delivered what he believes to be the final set of updates to
Sightline in support of this project. Sightline is in the process of
testing these deliverables and we expect that the results will be at or
close to what was expected. If there are still gaps, we will of course work
to close them.
As of today, there are still 13.5 hours of Dmitry's time left available
under the most recent contract extension. This should provide adequate time
for any consultation needed and any updates and/or final tuning necessary.
I have attached a brief report on that burn to this email. Steve, I will
send you a more detailed version that you can share inside Sightline as
needed.
Please let me know if you have any questions or concerns.
While I will continue to be in touch as we close down the project, I want
to take this opportunity to thank everyone involved for all their work. I
am confident I speak for all of us at Linaro when I say I hope we have the
opportunity to work with Sightline Applications again in the future.
Kind regards,
Paul
--
[image: Linaro] <http://www.linaro.org/>
Paul Neuhardt | *Sr. Program Manager*
T: +44 0771 377 8664
paul.neuhardt(a)linaro.org <glen.valante(a)linaro.org>
IRC: pneuhardt
Hello,
The package from Lantronix has arrived at the customs. Could you
please send me the corresponding invoice? I need it for customs
clearance. Thank you!
--
With best wishes
Dmitry
Hi Patrick,
On 21/03/2023 17:31, Patrick Whewell wrote:
> Hi Dmitry,
>
> I was looking for the device tree for the lantronix 5165 SOM and the schematics and attached are all of that.
>
> For the device tree I was trying to package up all of the individual includes, but it became too much so I decided to try and put it all in one file. To do this I used following commands:
>
>
> I preprocessed the dts file so that it would pull all the includes into one
>
> cpp -nostdinc -I ../../../../../../include -undef -x assembler-with-cpp qrb5165-iot-openq.dts > qrb5165-iot-openq.tmp.dts
>
> and then I tried to sort the file using the dtc
>
> dtc -I dts -O dts -o compiled.dts -s -@ qrb5165-iot-openq.tmp.dts
>
>
> Let me know if you would like it in a different format. I got some warnings while doing this, but no errors that I could see and the file looks like it should. Since it's such a large file (more than 3x as many lines as the upstream dts for qrb5165) it's sort of hard to make sure it's accurate.
>
> If you'd like any more schematics I can try to find more, but these should be what you were expecting.
Thank you, I will take a look.
>
> Patrick Whewell | Software Engineer | SightLine Applications, Inc | Onboard Video Processing
>
> -----Original Message-----
> From: Patrick Whewell
> Sent: Thursday, March 16, 2023 12:19 PM
> To: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
> Subject: RE: Linaro kernel for QRB5165
>
> Hi Dmitry,
>
> Yes that is correct that we bought a board and sent it to you. I don't have any updates, but there isn't anything on our end that is holding up the delivery. I do want to mention that the higher priority is the work that you are doing for us with the Snapdragon 820c chip with the thermal GPU issue. And that anything with the 5165 should be second to that.
>
> In the coming days me and a co-worker here are going to try and get the Thundercomm board up and running with the Linaro kernel. Currently we are waiting for approval to access some documentation. We wanted to start with the Thundercomm instructions and then move to the Linaro stuff after using the board and making sure it all worked as expected. According to their README we need access to the MULTIDL_TOOL_USER_GUIDE. I only mention this because I wanted to provide context for the fact that I'm not in a rush.
>
> I will work on trying to get you access to the files that you mentioned. The device tree files have a lot of #include so I will track those down and try to package them up nicely for you and see if I can find the schematics. I appreciate all the information so far. It's pretty hard trying to find information on this type of stuff and I personally find it interesting so I'm excited to research more on some of these new things you mentioned.
>
> Patrick Whewell | Software Engineer | SightLine Applications, Inc | Onboard Video Processing
>
> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
> Sent: Wednesday, March 15, 2023 1:22 PM
> To: Patrick Whewell <patrick.whewell(a)sightlineapplications.com>
> Subject: Re: Linaro kernel for QRB5165
>
> Hi Patrick,
>
> On Wed, 15 Mar 2023 at 19:17, Patrick Whewell <patrick.whewell(a)sightlineapplications.com> wrote:
>>
>> Thanks for that info! That explains why I couldn't figure out how it was selecting from the dtb appened to the kernel image. We'd like to eventually be able to use the Linaro kernel on the Lantronix board for testing. I can help supply some information but I believe it is supplying the vendor files.
>>
>> Lantronix provides a script that downloads and builds the kernel automatically but the relevant information is the following:
>>
>> In the repo manifest this is the information for the kernel:
>>
>> <remote fetch="https://source.codeaurora.org/" name="caf"
>> review="codeaurora.org"/> <default remote="caf"
>> revision="LU.UM.1.2.1.r1.3"/> <project groups="cyborg"
>> name="kernel/msm-4.19" path="src/kernel/msm-4.19"
>> revision="a103f94094dc38bc5931ca8559754e99558c0326"
>> upstream="LU.UM.1.2.1.r1.3"/>
>
> This is the public Qualcomm release of their 4.19 kernel
>
>> And the device tree that they use are located under:
>>
>> src/kernel/msm-4.19/arch/arm64/boot/dts/vendor/qcom/qrb5165-iot-openq.
>> dts
>
> And this is a proprietary device tree, written by Lantronix.
>
> I think Sightline has ordered a device kit, which should be delivered to me at some point. After I get it, I should be able to use its serial ID to get access to documentation and schematics of the board.
> Then we can port Linux kernel to their SoM/device kit. If you can provide SoM and base board schematics beforehand, it would speed up porting. Another option would be sharing the respective dts files to give us at least some kind of information regarding the board.
>
>> So I wouldn't be able to copy the needed files over and replace the device tree that is appeneded currently to the linaro kernel with the one from the Lantronix BSP? Our hope is to possibly get the linaro kernel running on the Lantronix board. If we want to do that, what would be some steps that we could take? We also purchased the Thundercomm platform so I can at least get that up and running but it'd be good to know why the Lantronix device tree wouldn't work with the kernel that is mentioned on the 96boards website.
>
> Thundercomm RB5 device is supported out of the box by the upstream kernel, see the qrb5165-rb5.dts file. Also you might be interested in the qrb5165-rb5-vision-mezzanine.dts which provides additional support for the cameras found on the Vision/Navigation mezzanine (included in the default RB5 kit). The former dts is available since 5.10, receiving incremental updates as the time goes. The later dts was merged into Linux 6.2.
>
> Unfortunately, you can not use device trees from Qualcomm releases with the upstream Linux kernel. Qualcomm writes them in a way that is not acceptable for the upstream kernels. Thus usually we have to repeat the porting up to some point.
> Basic steps to port Linux to the new Qualcomm-based board are the following:
> - Identify used PMICs.
> - Create the empty device tree including SoC and PMIC dtsi files.
> - Identify used UART and regulator tree. At this point the kernel should be bootable using debugging initramfs image.
> - Fill in the regulators description in the board dts
> - Identify storage options (eMMC, UFS, etc).
> - Identify used bus instances (I2C, SPI, corresponding QUPv3 wrappers, PCIe, USB)
> - Enable corresponding device nodes. Fill necessary supplies. Write corresponding pinctrl states.
> - Add support for the rest of necessary onboard devices, which can include sound codes, camera sensors, panel, DSI bridges/panels, etc.
> This might require writing additional drivers if the particular hardware piece is not supported.
>
>>
>> Thanks again!
>>
>> Patrick Whewell | Software Engineer | SightLine Applications, Inc |
>> Onboard Video Processing
>>
>> -----Original Message-----
>> From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
>> Sent: Wednesday, March 15, 2023 2:40 AM
>> To: Patrick Whewell <patrick.whewell(a)sightlineapplications.com>
>> Subject: Re: Linaro kernel for QRB5165
>>
>> Hi Patrick
>>
>> On 14/03/2023 21:24, Patrick Whewell wrote:
>>> Hi Dmitry,
>>>
>>> I work over at Sightline Applications and I am working on the
>>> Lantronix SOM of the qrb5165. We had a meeting at the beginning of
>>> the month to talk about some additional help (on top of the
>>> snapdragon 820c work) regarding this kernel and it was mentioned
>>> that you were pretty familiar with the qrb5165.
>>>
>>> I recently was able to find out the device tree that Lantronix is
>>> using in their kernel and my hope was to copy over the files needed
>>> to the Linaro repo, build, and hopefully use fastboot boot to test it out.
>>>
>>> My question is that I notice the Linaro Kernel is building and then
>>> appending two separate .dtb files to the end of the kernel. I have
>>> previously worked on systems with u-boot where you select the
>>> fdt_file in the u-boot environment. How does this kernel/chip
>>> determine which device tree blob to use. I was thinking that it
>>> would just pick the first one appended but then it would be
>>> pointless to attach two separate blobs in that case.
>>
>> Yes, unfortunately Qualcomm adopted to use Android boot images and their own proprietary bootloader rather than using one of the standard ones.
>>
>> The bootloader looks for the 'best match' while looking for the DTB. To accomplish this, it uses DTB's qcom,msm-id, qcom-board-id and qcom,pmic-id to compute the dts 'score', then it uses the DTS with the best score. For example this allows Android team to bundle a single image with DTBs for both RB3 and RB5 boards, with the correct DTB being selected at runtime.
>>
>> In theory this should also allow you to use a single image for APQ8096 and QR5165 boards. However for the bringup I suggest ignoring that possibility and always using just a single DTB, suitable for your board.
>>
>> Note: I do not yet have access to Lantronix BSP. If it provides the vendor kernel (and thus vendor DTS), these files are not going to be compatible with the upstream kernel.
>>
>>>
>>> Thanks!
>>>
>>> *Patrick Whewell*
>>>
>>> *Software Engineer*
>>>
>>> He/him
>>>
>>> _patrick.whewell(a)sightlineapplications.com
>>> <mailto:patrick.whewell@sightlineapplications.com>_
>>>
>>> www.sightlineapplications.com
>>> <http://www.sightlineapplications.com/>
>>>
>>> /5711 S Hood Ave., Suite 100/
>>>
>>> /Portland, OR 97239/
>>>
>>> <http://sightlineapplications.com/>
>>>
>>
>> --
>> With best wishes
>> Dmitry
>>
>
>
> --
> With best wishes
> Dmitry
--
With best wishes
Dmitry
Hello,
Moving the discussion to the project mailing list, so that it is
available to all interested parties.
---------- Forwarded message ---------
From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
Date: Wed, 15 Mar 2023 at 22:22
Subject: Re: Linaro kernel for QRB5165
To: Patrick Whewell <patrick.whewell(a)sightlineapplications.com>
Hi Patrick,
On Wed, 15 Mar 2023 at 19:17, Patrick Whewell
<patrick.whewell(a)sightlineapplications.com> wrote:
>
> Thanks for that info! That explains why I couldn't figure out how it was selecting from the dtb appened to the kernel image. We'd like to eventually be able to use the Linaro kernel on the Lantronix board for testing. I can help supply some information but I believe it is supplying the vendor files.
>
> Lantronix provides a script that downloads and builds the kernel automatically but the relevant information is the following:
>
> In the repo manifest this is the information for the kernel:
>
> <remote fetch="https://source.codeaurora.org/" name="caf" review="codeaurora.org"/>
> <default remote="caf" revision="LU.UM.1.2.1.r1.3"/>
> <project groups="cyborg" name="kernel/msm-4.19" path="src/kernel/msm-4.19" revision="a103f94094dc38bc5931ca8559754e99558c0326" upstream="LU.UM.1.2.1.r1.3"/>
This is the public Qualcomm release of their 4.19 kernel
> And the device tree that they use are located under:
>
> src/kernel/msm-4.19/arch/arm64/boot/dts/vendor/qcom/qrb5165-iot-openq.dts
And this is a proprietary device tree, written by Lantronix.
I think Sightline has ordered a device kit, which should be delivered
to me at some point. After I get it, I should be able to use its
serial ID to get access to documentation and schematics of the board.
Then we can port Linux kernel to their SoM/device kit. If you can
provide SoM and base board schematics beforehand, it would speed up
porting. Another option would be sharing the respective dts files to
give us at least some kind of information regarding the board.
> So I wouldn't be able to copy the needed files over and replace the device tree that is appeneded currently to the linaro kernel with the one from the Lantronix BSP? Our hope is to possibly get the linaro kernel running on the Lantronix board. If we want to do that, what would be some steps that we could take? We also purchased the Thundercomm platform so I can at least get that up and running but it'd be good to know why the Lantronix device tree wouldn't work with the kernel that is mentioned on the 96boards website.
Thundercomm RB5 device is supported out of the box by the upstream
kernel, see the qrb5165-rb5.dts file. Also you might be interested in
the qrb5165-rb5-vision-mezzanine.dts which provides additional support
for the cameras found on the Vision/Navigation mezzanine (included in
the default RB5 kit). The former dts is available since 5.10,
receiving incremental updates as the time goes. The later dts was
merged into Linux 6.2.
Unfortunately, you can not use device trees from Qualcomm releases
with the upstream Linux kernel. Qualcomm writes them in a way that is
not acceptable for the upstream kernels. Thus usually we have to
repeat the porting up to some point.
Basic steps to port Linux to the new Qualcomm-based board are the following:
- Identify used PMICs.
- Create the empty device tree including SoC and PMIC dtsi files.
- Identify used UART and regulator tree. At this point the kernel
should be bootable using debugging initramfs image.
- Fill in the regulators description in the board dts
- Identify storage options (eMMC, UFS, etc).
- Identify used bus instances (I2C, SPI, corresponding QUPv3 wrappers,
PCIe, USB)
- Enable corresponding device nodes. Fill necessary supplies. Write
corresponding pinctrl states.
- Add support for the rest of necessary onboard devices, which can
include sound codes, camera sensors, panel, DSI bridges/panels, etc.
This might require writing additional drivers if the particular
hardware piece is not supported.
>
> Thanks again!
>
> Patrick Whewell | Software Engineer | SightLine Applications, Inc | Onboard Video Processing
>
> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
> Sent: Wednesday, March 15, 2023 2:40 AM
> To: Patrick Whewell <patrick.whewell(a)sightlineapplications.com>
> Subject: Re: Linaro kernel for QRB5165
>
> Hi Patrick
>
> On 14/03/2023 21:24, Patrick Whewell wrote:
> > Hi Dmitry,
> >
> > I work over at Sightline Applications and I am working on the
> > Lantronix SOM of the qrb5165. We had a meeting at the beginning of the
> > month to talk about some additional help (on top of the snapdragon
> > 820c work) regarding this kernel and it was mentioned that you were
> > pretty familiar with the qrb5165.
> >
> > I recently was able to find out the device tree that Lantronix is
> > using in their kernel and my hope was to copy over the files needed to
> > the Linaro repo, build, and hopefully use fastboot boot to test it out.
> >
> > My question is that I notice the Linaro Kernel is building and then
> > appending two separate .dtb files to the end of the kernel. I have
> > previously worked on systems with u-boot where you select the fdt_file
> > in the u-boot environment. How does this kernel/chip determine which
> > device tree blob to use. I was thinking that it would just pick the
> > first one appended but then it would be pointless to attach two
> > separate blobs in that case.
>
> Yes, unfortunately Qualcomm adopted to use Android boot images and their own proprietary bootloader rather than using one of the standard ones.
>
> The bootloader looks for the 'best match' while looking for the DTB. To accomplish this, it uses DTB's qcom,msm-id, qcom-board-id and qcom,pmic-id to compute the dts 'score', then it uses the DTS with the best score. For example this allows Android team to bundle a single image with DTBs for both RB3 and RB5 boards, with the correct DTB being selected at runtime.
>
> In theory this should also allow you to use a single image for APQ8096 and QR5165 boards. However for the bringup I suggest ignoring that possibility and always using just a single DTB, suitable for your board.
>
> Note: I do not yet have access to Lantronix BSP. If it provides the vendor kernel (and thus vendor DTS), these files are not going to be compatible with the upstream kernel.
>
> >
> > Thanks!
> >
> > *Patrick Whewell*
> >
> > *Software Engineer*
> >
> > He/him
> >
> > _patrick.whewell(a)sightlineapplications.com
> > <mailto:patrick.whewell@sightlineapplications.com>_
> >
> > www.sightlineapplications.com <http://www.sightlineapplications.com/>
> >
> > /5711 S Hood Ave., Suite 100/
> >
> > /Portland, OR 97239/
> >
> > <http://sightlineapplications.com/>
> >
>
> --
> With best wishes
> Dmitry
>
--
With best wishes
Dmitry
--
With best wishes
Dmitry