[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

[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 1 year, 1 month ago by gil_he.

[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,

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

[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 1 year, 1 month ago by gil_he.

[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]

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 1 year, 1 month ago by gil_he.

Attachments:

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

[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]

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_he]

Hi Neeraj,

The gibberish was shown using two different usb-serial adapters.

I know these adapters connect successfully to a 3.3V serial bus.

The only explanation I can find is that the stlink is specifically required to interpret correctly the SoC uart data.

I assume this can be verified with ST.

thanks

Gil

[gil_he]

Hi Neeraj,

Behavior is the same in BRK, RED and in our board.

The UART in the SiP sends the correct baud rate. In addition, electrically, the signals are correct.

It seems the debugger is sending the ascii symbols properly, and the terminal shows them correctly.

When connecting the SiP directly to a serial to usb and to a pc, I see gibberish.

The only explanation I have is, something in the debugger (fw or hw) translates the SiP uart correctly to the terminal.

Gil

[gil_he]

hi Neeraj,

An update:

I was able to receive readable uart4 output (not gibberish) ONLY when using the STLINK (as a uart to usb interface).

Direct connection of the SiP uart interface (via generic serial to usb), using numerous terminals, showed only gibberish.

thanks

Gil

 

 

[gil_he]

Hi Neeraj,
1. We don’t use a chip like the STUSB1600. The SiP USB port is connected directly to the type c connector (as I described above).
The type C is just a connector. We work with it as if it’s USB2.
The CC pins are NC in the type C connector.
See attached picture. We also don’t use the OTG_HS_ID.
Setting on the CubeMX is OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.
To your understanding, is that ok?

2. I tried many different setups using Putty. Always giberish.
I will further debug the uart4.

thanks

Gil

• This reply was modified 2 years, 3 months ago by gil_he.

Attachments:

1. 

   usb_lucid40.png
   

[gil_he]

hello Neeraj,

(1)

Regarding the USB configuration:

We have the USB port in the SiP connected to a USB Type C connector.

VBUS in the connector is connected to the SiP.

Our device will act as a peripheral (device) and DRD. PA10 is not connected.

The only pins connected to the type C are USBDP2/DM2 and OTG_VBUS.

See enclosed picture from CubeMx: We defined OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.

Is the following setup correct?

(2)

We don’t have any other UART pins, in the SiP, that can be routed to the debug connector.

The only pins are for UART4 but not the default ones, so, until we change it (in UBOOT), we cannot use it.

(3)

We connected the UART4 connector in the Octavo BRK and RED, and see giberish on the terminal.

Trying all available settings (translations, com settings) did not help.

Why can’t we see clearly the logs on uart4?

thanks

Gil

• This reply was modified 2 years, 3 months ago by gil_he.

Attachments:

1. 

   CubeMx_USB_OTG.png
   

[gil_he]

hello Neeraj,

I’ve taken a correct CubeProgrammer sequence (from https://community.st.com/s/question/0D53W000007Y3WmSAK/using-stm32cubeprogrammer-v220-to-program-sd-card-of-our-board-the-board-is-base-on-stm32mp157cdk2-but-fail-and-get-error-messageerror-start-operation-failed-at-partition-0x01error-tsv-flashing-service-failed)
and compared to AN5275, figure 3, page 6.

I think, we passed the “Authenticate and start TF-A (in SYSRAM)”, so it seems our USBC port is configured as required (TF-A load is successful).
So, we are in either “Get boot config from BootRom” or “init clock and DDR” states.
Do you agree?
(I do not think we reached the “FlashLayout & start” state).

What can cause our start operation to fail?

Is it the files used to create the tf-a.stm32 binary?

Maybe the clock configuration tree?

Also:

The GenerateCode of the CubeMx gave us three files (under the TF-A folder):
stm32mp157c-lucid40_p1-mx-fw-config.dts
stm32mp157c-lucid40_p1-mx.dts
stm32mp15-mx.dtsi

The file, stm32mp157c-lucid40_p1-mx-fw-config.dts, has an include to a dtsi file which we don’t have.
It has only these two lines:
#define DDR_SIZE 0x20000000 /* 512MB */
#include “stm32mp15-fw-config.dtsi”

Should we rename the include to “stm32mp15-mx.dtsi”?

thanks

Gil

• This reply was modified 2 years, 3 months ago by gil_he.
• This reply was modified 2 years, 3 months ago by gil_he.

[Author]

Posts