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
Hi
Are you interested in purchasing XPONENTIAL 2023 Updated Database?
Attendees:
Researchers, Executives, Engineers, program managers, policymakers, and end users...
Record in the list contains: Contact Name, Job Title, Company/Business Name, Complete Mailing Address, email, Telephone/Fax Number, Website/URL, Revenue, Employee Size, SIC Code, Industry.
If you are interested to purchase reply back as "Send Counts and Pricing".
Thank you,
Margaret - Marketing Director
USA & Europe
Hello,
A set of updates from our side.
0) We have started the process of migrating our repositories to new
service. Please consider migrating the repository url on your side from
git.linaro.org to https://git.codelinaro.org/linaro/qcomlt/kernel/ .
The branch name states intact (release/db820c/qcomlt-5.15)
The old repository location will mirror the new location, but it might
take some time for the changes to propagate to it.
1) I have pushed a set of patches fixing two issues I narrowed down
during my tests of the GPU. I will continue working on the driver.
2) Regarding fixing the GPU clocks. Please consider applying the
attached patch, which should fix the minimum clock rate to 510 MHz.
If I interpret your last test results correctly, the issue really is in
the GPU rate handling, so this patch should provide a workaround.
--
With best wishes
Dmitry
Hi Paul,
We discussed here and think we should postpone our first meeting until next Wednesday as we don't really have any new information to discuss tomorrow. Is this ok with you?
Thanks,
Kim
-----Original Appointment-----
From: Kim Steiner
Sent: Tuesday, January 10, 2023 6:04 AM
To: paul.neuhardt(a)linaro.org
Subject: Accepted: Bi-Weekly SightLine/Linaro Sync
When: Occurs every 2 week(s) on Wednesday effective 1/18/2023 from 4:00 PM to 5:00 PM Europe/London.
Where:
All,
As we discussed before the holidays, in the future, we should conduct a
regular cadence of status/update meetings between Linaro and SightLine
Applications. The purpose would be to sync on what activity has been done,
what issues have come up and what the work plans for the upcoming two weeks
are. Would 8:00 am PST on Wednesdays work, starting next week (18 January)?
If not, what time/date early in your days would work for you? Once we
settle on that, I will send out an invitation to everyone.
I don't know that everybody needs to attend these meetings, so I leave
it up to you to determine who from SightLine would need to attend. From
Linaro it would be me, Vinod, and the engineering team working on the
project, with Nico attending as time permits.
Thanks.
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
All,
As expected and as I communicated previously, the latest work done by
Dmitry has exhausted the remaining balance of the latest Purchase Order. I
believe we are close to the end of the defined work, and Dmitry is
finishing up the last of the thermal changes now for final delivery this
week.
We will continue to respond to basic questions regarding what has been
delivered to date, but additional work will require an additional extension
to the ongoing agreement. We would be happy to discuss an extension to
continue this thermal work or any other work you might wish us to help
with. Let me know your thoughts on this and we can proceed from there.
Either way, a review meeting would seem to be in order, either to wind down
this project or determine the path forward should it continue. Would the
relevant people from Sightline be available this week? If not, when might a
good time be for you?
I look forward to hearing from you.
Best 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 All,
Over the past few weeks Dmitry made significant progress. We have asked
him to focus his time and efforts almost exclusively on your work in order
to complete all of what we agreed upon. During this push he has nearly
completed the work with the Kryo and SPM regulators. Once those are done,
he will complete the overall work by tying everything into the CPR3 driver.
This last push has consumed the remaining engineering time on the second PO
you authorized, and we have not yet completed the work at hand. I've worked
with Dmitry to get the best estimate possible on what it will take to
complete the work, and we are looking at 8 engineering days. At the rate of
$2,000 per day, that is an additional $16,000. Given that I have not
expended all the PM time authorized in the two agreements already reached,
I do not believe any more budget for project management will be necessary.
I know this is the second time we have come back after exhausting our
estimates, and I can only apologize for that. Several items have turned out
to be more complex than we had anticipated. But we are now very confident
that we have an accurate estimate on the last push to complete the work for
you. We understand how important this work is to your product line, and we
are dedicated to getting the work completed at a high level of quality and
in a way that will support your business.
Please let me know if you wish to continue with the work, and we will send
an additional extension request for approval. Terms would be paid in 30
days as before, with work to resume immediately. I believe we should have
another meeting to discuss where we go from here and the options for
completing the work. I suggest 9:00 PDT on Tuesday, 11 October (5:00 pm
BST, 6:00pm CET). Please let me know if that works for you, and if it does
not when would be a good time.
Thank you.
Kind regards,
Paul Neuhardt
--
[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
All,
As of Friday of last week, Dmitry has completed his work on the CPR-GFX. He
is currently investigating issues during power up of the GPU, where GPU
clocks sometimes fail to start.
At the moment I do not have a full accounting of Dmitry's time spent on the
project for last week, but I will forward that in future updates as soon as
I have it.
I spent 0 hours on the project last week as I was out of office on holiday.
As always, if you have any questions or concerns please let me know.
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
All,
As of Friday, 23 September 2022, Dmitry has begun the work required in the
CPU regulators. Once that work is done, he will integrate that work with
the CPR work already completed. He estimates roughly 4 engineering-days of
effort are required to complete that work and turn the images over for
Sightline testing.
As he mentioned last week, Dmitry is out of the office this week. He will
resume work on his return next Monday.
I would recommend a check-in meeting for the following week to assess the
work done to that point, the testing required to validate the work done,
and to start discussion around how to complete and ramp-down the project.
Would Tuesday, 18 October work for everyone?
Thanks.
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
