Linux Kirkstone 5.15

[gil_he]

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

• This topic was modified 7 months, 2 weeks ago by gil_he.

[Eshtaartha Basu]

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.

[gil_he]

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

 

[Neeraj Dantu]

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

[gil_he]

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

[gil_he]

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

• This reply was modified 7 months, 1 week ago by gil_he.

Attachments:

1. first.txt
2. second.txt
3. third.txt

[Neeraj Dantu]

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

[gil_he]

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

[gil_he]

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

• This reply was modified 7 months, 1 week ago by gil_he.

[Neeraj Dantu]

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

[gil_he]

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

Attachments:

1. exti_pwr_node.docx

[Neeraj Dantu]

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

[gil_he]

hello Neeraj,

Please see the attached files for details (“main” then “5_15_67_log”).

Do you have any suggestions for us?

thanks,

Gil

Attachments:

1. main.txt
2. 5_15_67_log.txt

[gil_he]

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

• This reply was modified 7 months ago by gil_he.

[Neeraj Dantu]

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

• This reply was modified 6 months, 4 weeks ago by Neeraj Dantu.

[gil_he]

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

[Author]

Posts