[coloradocarlos]

Yes, for the last 6 weeks I was getting messages to the effect that my posts were waiting to be moderated. Nothing was showing up.

[coloradocarlos]

Testing 1, 2, 3. Did this post go through?

[coloradocarlos]

We reviewed using the line in PMIC_PONKEYn and decided that there is some risk in using it. The PONKEYn is not only used for power on but for shutdown too. A spurious signal could cause the board to shutdown unexpectedly.

To be more specific, PC13 can be the RTCOUT1 output during VBAT mode (I found you need to set the right bits in RTC_CR). This could complicate using PC13 for external events to trigger a wakeup. Given this background, is PC13 a supported input or is it considered “for internal use only”?

[coloradocarlos]

Sorry, I found the solution, I should have updated this topic with the fix.

Indeed systemd is controlling the power key event and needs to be changed to respond to poweroff.

To troubleshoot, first determine if the root user session is ignoring the power key.

loginctl show-user

1	loginctl show-user

If HandlePowerKey=ignore, then run systemd-analyze to find out where it is set.

systemd-analyze cat-config systemd/logind.conf --no-pager

1	systemd-analyze cat-config systemd/logind.conf --no-pager

The key is ignored in /lib/systemd/logind.conf.d/01-openstlinux.conf. Apparently, ST didn’t think it was a good idea to respond to a PONKEYn to poweroff a board.  To override, create a file in /lib/systemd/login.conf.d/ named  02-osd32mp1-myboard.conf

[Login] HandlePowerKey=poweroff

1 2	[Login] HandlePowerKey=poweroff

Then restart systemd-logind:

systemctl restart systemd-logind

1	systemctl restart systemd-logind

I fixed this in my own Yocto layer with a custom bbappend. Should this be changed in the Octavo layer? I don’t know. Depends on what you think the PONKEYn should do or not while the system is running.

One other gotcha. In the TF-A device tree, the STM32_PM_SHUTDOWN may not be honored. In other words, suspends but not a total poweroff and you encounter a watchdog timeout which reboots the board. The workaround is to emit a message to the console in stm32mp1_pm.c.  See this link for details: https://github.com/Seeed-Studio/meta-st-odyssey/issues/5. Happy patching!

[coloradocarlos]

ST announced today (6/30/2022) STM32MPU ecosystem release v4.0.0 with kirkstone support: https://community.st.com/s/question/0D53W00001dwKXQSA2/stm32mpu-ecosystem-release-v400-release-is-online-

[coloradocarlos]

I reviewed the Getting Started documentation and it appears that the OTG_ID pin is used only for USB Micro-AB connectors. In other words, it is not used for USB Type-C connectors. Same for VBUS– it can’t be used directly unless there is an intermediate circuit such as the STUSB1600 that can detect role switches. Is this correct?

[coloradocarlos]

Ashvin,

I am having technical trouble viewing your recent correspondence.

You asked about SPI code running on the MCU. Try running one or more of these demos for the DK2. With slight modification, they run on the Octavo line of SIP’s:

https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Examples/SPI

Also the PZ0, etc. pins are secure pins defined in pinctrl_z. You may need to review the secure bootloader DTS configuration in TF-A or OP-TEE. I worry you may be having problems due to the security mechanism. Try the unsecure pins and see if you have the same problems.

Regards, Carlos

[coloradocarlos]

The suspend to “s2idle” is interesting. I would expect “deep” for the low power modes. Transitioning to low power is a bit more complicated because it includes coordination between the MPU and MCU. Are you running an app (firmware) on the M4 that happens to be using DMA? Try stopping the firmware and see if you can duplicate the behavior.

[coloradocarlos]

Is the same behavior observed on the SPI CLK pin(s) for an unmodified version of the SD card image from Octavo? Which version of the kernel (SD card image) are you using? On the A7 side, is the “SPI communications” you are using the Linux spidev driver?

[coloradocarlos]

If you refer to the DMA driver in stm32-dma.c, the suspend code checks the EN bit (Stream Enable) in register DMA_SxCR. See page 1217 of the RM0436 which states:

Bit 0 EN: stream enable / flag stream ready when read low
This bit is set and cleared by software.
0: stream disabled
1: stream enabled
This bit may be cleared by hardware:
– on a DMA end of transfer (stream ready to be configured)
– if a transfer error occurs on the AHB master buses
– when the FIFO threshold on memory AHB port is not compatible with the size of the burst

So something related to the DMA controller. Of interest is the AHB. By any chance, do you have a ST-LINK debugger connected to BRK board?

Carlos

[coloradocarlos]

Another thing to check for is the file arch/arm/dts/osd32mp1-xyz-u-boot.dtsi. I didn’t see it in your original list of files that you copied but is created by 0001-Add-OSD32MP1-RED-Device-Tree-support.patch. This is the “U-Boot DTSI options” file. The build will succeed even if this file does not exist. Even though it is an “include file”, it is not included anywhere and is build separately (if it exists). See line 165 of scripts/Makefile.lib to see what I mean.

[coloradocarlos]

You are on the right track because I have done something similar to successfully rename the board.

Since U-Boot seems to be failing, I suggest first checking in ./deploy/bootfs. Make sure the directory layout and files are correct. In particular, make sure the extlinux.conf file points to the right DTB.

If all seems well, then rebuild the file system by running “make bootfs” in the docker container. This will make sure the *.stm32 file is up-to-date. Then try re-flashing.

Lastly, you should always be able to boot off a good SD card regardless of the state of the eMMC. Sometimes I forget to reset the boot switches after flashing.

[coloradocarlos]

Are you using the Docker container provided by Octavo to build your binaries? It works great and the environment is set up to cross-compile for the arm:

OSD32MP1 Debian SDK – Develop Debian images for OSD32MP1
https://github.com/octavosystems/osd32mp1-debian-docker
1 forks.
0 stars.
0 open issues.

Recent commits:

• Merge pull request #1 from octavosystems/osd32mp1-v3.0Update README.md, GitHub
• Update README.md, GitHub
• Update README for SDK v3.0, GitHub
• Update README.md, GitHub
• Update README.md, GitHub

[coloradocarlos]

Part of the Debian build process is setting the type of bootloader images to build. I am trying reproduce the Debian build steps for the BRK board and would like to know if we should be using “basic” build versus the “trusted” build. So rather than using the trusted image for the FSBL, we should use U-Boot SPL instead.

The reason I say this is the SD card image boots up with this message to the console:

U-Boot SPL 2018.11-stm32mp-r4 (May 07 2020 – 20:20:42 -0500)
Model: Octavo Systems OSD32MP1-BRK Board
RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
Trying to boot from MMC1

Since I am using a custom board with the 800 MHz processor, U-Boot displays “basic mode” for the STM32MP157F:

U-Boot 2018.11-stm32mp-r4 (May 07 2020 – 20:20:42 -0500)

CPU: STM32MP157F?? Rev.Z
Model: Octavo Systems OSD32MP1-BRK Board
Board: stm32mp1 in basic mode (st,stm32mp157c-brk)
DRAM: 512 MiB

• This reply was modified 2 years, 10 months ago by coloradocarlos.

[coloradocarlos]

Here is a script that works on the BRK to display the ADC temperatures. I found that the temperature device driver is disabled on the RED so you will need to enable it in the device tree for this to work.

EDIT: I am not sure why stray HTML tags are getting injected in the code block below. You will need to fix this before running the script.

#!/bin/sh # See: https://elixir.bootlin.com/linux/v4.19.94/source/Documentation/ABI/testing/sysfs-bus-iio dir='/sys/bus/platform/drivers/stm32-adc-temp/48003000.adc:temp/iio:device2' raw=<code>cat $dir/in_temp_raw offset=<code>cat $dir/in_temp_offset scale=<code>cat $dir/in_temp_scale printf "Value read: raw %0f\n" $raw printf "Value read: offset %0f\n" $offset printf "Value read: scale %0f\n" $scale temperature=<code>echo &quot;scale=3;($raw*$scale + $offset*$scale) / 1000&quot; | bc echo "Temperature $temperature C" printf "Temperature %.01f C\n" $temperature

1 2 3 4 5 6 7 8 9 10 11 12

#!/bin/sh # See: https://elixir.bootlin.com/linux/v4.19.94/source/Documentation/ABI/testing/sysfs-bus-iio dir='/sys/bus/platform/drivers/stm32-adc-temp/48003000.adc:temp/iio:device2' raw=<code>cat $dir/in_temp_raw offset=<code>cat $dir/in_temp_offset scale=<code>cat $dir/in_temp_scale printf "Value read: raw         %0f\n" $raw printf "Value read: offset      %0f\n" $offset printf "Value read: scale       %0f\n" $scale temperature=<code>echo &quot;scale=3;($raw*$scale + $offset*$scale) / 1000&quot; | bc echo "Temperature $temperature C" printf "Temperature %.01f C\n" $temperature

 

• This reply was modified 3 years ago by coloradocarlos. Reason: weird html chars in code block
• This reply was modified 3 years ago by coloradocarlos. Reason: Note the odd HTML tags in the post

[Author]

Posts