Forums › Devices › OSD32MP15x › Linux Kirkstone 5.15
hello,
We are using OSD32MP153C-512M-BAA and need to configure the internal SPI controller as a slave, that connects to the A7 (running Linux).
Does Octavo have patches that support Linux Kirkstone 5.15? (which is the Linux version that supports SPI slave configurations).
thanks
Gil
Hello gil_he,
We do provide meta-layer for Kirkstone support – https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone
The README has all the information required to build and use the layer.
Dear Eshtaartha,
Thank you for your reply.
We followed the guidelines.
The meta-layer Kirkstone support has Linux version 5.15.24.
It DOES NOT support SPI slave configurations.
Only from Linux version 5.15.67 SPI slave is supported.
Can we build the 5.15.67 Linux version and use the patches in your 5.15.24 version support?
thanks
Gil
Gil,
You should be able to use the kirkstone patches with 5.15.67. There are not any kernel level modifications that would affect the compilation.
Best,
Neeraj
Hi Neeraj, Eshtaartha,
Thank you.
I am unable to reply to you with the full information I need to enclose.
I just sent an email to Martin Burgos, asking him to forward it to you.
thank you
Gil
Hi Neeraj, Eshtaartha,
I input the information to three text files.
Please read them in this order: first.txt, second.txt, third.txt.
It is more updated and detailed than what I sent Martin.
Thank you
Gil
Gil,
You are correct, it looks like 1 of the patches from ST failed to apply because the file it was modifying was too different. The patch that is failing is from ST. You will need to resolve the error by reviewing the code being modified by the patch and making sure the modification applied by the patch is still valid and will function correctly.
An easier way probably would be to pull the kernel source from ST’s repository here: https://github.com/STMicroelectronics/linux/tree/v5.15-stm32mp-r2 (This code has all the ST patches already applied).
If you need granular control of the kernel source code, I suggest you look at https://wiki.st.com/stm32mpu-ecosystem-v4/wiki/OpenEmbedded_-_devtool to export the kernel code into its own workspace and make modifications/resolve conflicts in the source code.
Best,
Neeraj
hello Neeraj,
Well, totally eight of the patches fail.
We need kernel version 5.15.67 (or later) for the SPI slave support. Do you know if the kernel code from ST, you directed me to, is what we need?
Are all the required patches from ST only? Doesn’t we need also Octavo-created patches to be applied to the build of the 5.15.67 based Linux, so it can run on the SiP we use?
thanks,
Gil
hello Neeraj,
Adding information to my above message:
We downloaded the kernel source from ST’s repository (where all the ST patches are already applied).
Some of the patches from the 5.15.24 do fail on the 5.15.67, but 14 patches fully pass.
So, some patches from the 5.15.24 are required for the 5.15.67. And some fail since they are already applied.
So, we can try and manually correct the failing patches.
Question is: Do we need also Octavo-created patches to be applied to the build of the 5.15.67 based Linux, so it can run on the Octavo SiP we use?
Will the 5.15.24 Octavo patches run successfully on the 5.15.67 sources? Are those enough, from Octavo, for the 5.15.67?
thank you
Gil
Gil,
The patches that Octavo applies are for BRK an RED board. If your board is based on these boards, you will need the patches. If not, the 2 patches you need are the DDR parameters(for u-boot: stm32mp15-osd32mp1-ddr3-1x4Gb.dtsi or stm32mp15-osd32mp1-ddr3-2x4Gb.dtsi) for the specific DDR in use and https://github.com/octavosystems/meta-octavo-osd32mp1/blob/dunfell/recipes-bsp/u-boot/files/0009-Fix-device-tree-for-800MHz-speedgrade-MP1-to-work-wi.patch to add support for “F” variant devices to run on 650MHz.
For the custom board device tree, I recommend taking a look at BRK device tree to understand what you need to port to your custom device tree. For example, OSD32MP1 uses STPMIC1 and so, STPMIC1 related configuration in the device tree is needed for any OSD32MP1 based board.
All the Octavo patch files do not modify kernel source code. They add device tree source files for the supported boards. So, there should not be any issues with using .24 patches with .67 kernel version.
Best,
Neeraj
hello Neeraj,
We see an issue with how the device tree is handled in 5.15.67 versus 5.10 and 5.15.24.
Please see the attached file for details.
How do we proceed from here?
thank you
Gil
Gil,
Please change “&exti_pwr” to “&exti” as it looks like all the interrupts are being handled by the exti driver. This should fix the error you are encountering.
Best,
Neeraj
hello Neeraj,
Please see the attached files for details (“main” then “5_15_67_log”).
Do you have any suggestions for us?
thanks,
Gil
hello Neeraj,
Another question:
The U-Boot version we use is the one that comes with Dunfell:Â version: 2020.10
Should we use a more updated UBOOT version?
Are there any dependencies between the Linux kernel version and the UBOOT version?
thanks,
Gil
Gil,
The log you attached above indicates that the kernel is running into an error as soon as it takes control from u-boot. Increasing the log level can tell what exactly is going wrong. I do not believe that there is a dependency between U-Boot and kernel versions except for the boot command being passed on to the kernel from u-boot, but the boot process also involves other components: https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview#STM32MP15_boot_chain. Please note that ST has also changed the boot image layout between Dunfell and Kirkstone(https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout).
My recommendation would be to use Krikstone versions of everything for the 15.67 kernel.
Best,
Neeraj
Hi Neeraj,
The log level is at its maximum.
As soon as the kernel takes control, something goes wrong.
It doesn’t even reach a point where it can send a message to the UART so we can see it.
We saw a similar issue in some ST forum and it was suggested that there is a dependency between the kernel and UBOOT versions.
We will follow what you suggested and see how it goes.
thanks,
Gil
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields