Thomas,
Can you check the polarity and connection for MMC0_CD(card detect pin) of the SD card interface on your custom board? I suspect the SD card detect signal is either not hooked up the same as Pocketbeagle or the polarity is reversed. See https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf for the configuration of MMC0_CD in Pocketbeagle.
Check the pin and polarity of card detect pin(‘cd-gpios’) defined in the device tree here: https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/blob/v5.10.x-ti-unified/src/arm/am335x-pocketbeagle.dts#L799.
Best,
Neeraj
Eric,
Does this happen at random or all the time?
Is there additional circuitry connected to the BRK that is consuming current from the PMIC rails?
What is the environment temperature? Are you using an enclosure?
What is the current consumption of the board?
Best,
Neeraj
asd,
It seems like you found a hardware bug on the RED board. I was able to figure out the root cause after a chat with ST’s Engineer:
“TF-A is accurate when reporting the boot reason.”
This meant that NRST was being pulled LOW by another component. eMMC is the only device that has it’s RESET pin tied to NRST and it is powered by BUCK4. This is probably why if you have BUCK4 ON, you are not seeing the faulty behavior.
Once I disconnected eMMC’s RESET from NRST by cutting the trace, I was able to get the RED board into STANDBY without issue.
I was seeing variability in behavior before because I was using SD card interface to boot instead of eMMC. I suggest you use the SD card boot to work with low power modes that turn off BUCK4. I will add an issue to the design team to fix the hardware issue in the next revision.
Best,
Neeraj
asd,
Verified this behavior on RED v1.2. I will put in an issue with the software team. I suspect that it is a RED specific Debian service(weston?) that is preventing a proper enter into low power state. Please use the OpenSTLinux version to implement the deep sleep state for now. Will update here once I get an update.
Best,
Neeraj
Bow-Nan Cheng,
Internal Oscillator for PS_REF_CLK can be disabled by pulling down OSC_OE pin. PS_REF_CLK is available as package pin B26. Please see https://octavosystems.com/docs/osdzu3-ref-schematics/ for more information.
Best,
Neeraj
Simon,
The first thing to check would be if there is a back current on VDDSHV/SYS_VDD3_3P3V. This can happen if the IO of the processor are being driven/pulled-up by an external device that is still being powered after the PMIC power rails have come down. Please take a look at the power down sequencing of the PMIC in relation to the power down sequencing of the rest of the board.
Best,
Neeraj
Simon,
Appreciate the update. Thanks!
Best,
Neeraj
Ben,
Please see https://wiki.st.com/stm32mpu/wiki/CAN_overview, this page also links to a couple of other “How to” pages that might be useful.
Best,
Neeraj
Judy,
Have you looked at https://octavosystems.com/forums/topic/spi-nor-from-u-boot/#post-6713 in specific pinmux definitions that are needed?
Please also take a look at https://e2e.ti.com/support/processors-group/processors/f/processors-forum/758423/linux-am5718-qspi-boot-fail-spi-probe-failed with the same error. While the post is for a different device all the inputs should apply to AM335x.
Best,
Neeraj
Ed,
Please contact sales(at)octavosystems.com for a discussion on this.
Best,
Neeraj
Simon,
I cannot see the pictures you posted, not sure why. Here are some inputs based on your description:
On #1, These are digital IO of the PMIC, not sure if there is an issue with them going Low during power down.
On #2, can you check your PMIC registers, specifically 0x19 – 0x1E(see https://www.ti.com/lit/ds/symlink/tps65217.pdf) and make sure they correspond to ‘C’ version of the PMIC?
You can go through support if you are facing issues including/attaching images.
Best,
Neeraj
Marco,
The Linux kernel is already configured to use the DDR as needed. See https://github.com/STMicroelectronics/linux/blob/v6.1-stm32mp/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi#L20 for the device tree configuration of the DDR. Memory can be allocated and freed accordingly in your application.
Best,
Neeraj
Marco,
Assuming the ADC has an I2C interface, BRK has a number of I2C devices available. Please see https://octavosystems.com/octavosystems.com/wp-content/uploads/2020/05/Default-Pin-Mapping.pdf for pin-mux details. These I2C interfaces are exposed as /dev/i2cX, which you can use to communicate over. See for example: https://elinux.org/Interfacing_with_I2C_Devices, where several system calls are used to communicate over the I2C bus.
You can also enable the Linux Kernel driver available for the ADC using device tree: https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/I2C_device_tree_configuration. You will need to recompile your device tree and boot the board with the new device tree. The driver will provide several virtual files in the file system in /sys/class/i2c/ to configure the ADC as well as measure ADC inputs. See https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/How_to_compile_the_device_tree_with_the_Developer_Package for a software SDK that ST provides for compiling device tree.
Best,
Neeraj
Hey Marco,
The Getting Started Guide provides an introduction to the hardware and how to bring-up the board. As you said, it is a good starting point, but not a comprehensive guide to all functionality.
Having said that, the goal of the MP1 family from both ST and Octavo perspective is to provide a good path to customers such as yourself to MPU and Embedded Linux. There is a lot of support documentation to achieve this. I will try to provide some useful info below:
1. Start here on ST’s Wiki that talks about basic platform functionality and features of the SoC: https://wiki.st.com/stm32mpu/wiki/STM32MP15_microprocessor
2. https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/Getting_started/STM32MP1_boards/STM32MP157x-DK2 provides a little more detailed guide on how to write applications for A7 and M4 cores. Most of the procedure should be applicable for the BRK as well.
3. https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/Category:How_to links to a number of pages that explain how to do a specific task.
4. https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/Category:Linux_Operating_System provides information on almost all peripherals, their drivers and how to use them: https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/Category:Linux_Operating_System
For example, please see https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/How_to_control_a_GPIO_in_userspace for the user space program to control GPIOs that you are looking for.
I would also advise you on learning a little more about Linux and SYSFS. A lot of how you do things in Linux is by way of writing to virtual device “files” like /dev/gpiochip0 or using command line to execute individual commands or shell scripts that set configuration and ask the kernel to execute system calls.
Octavo provides Debian SDK(https://github.com/octavosystems/osd32mp1-debian) and OpenSTLinux layer(https://github.com/octavosystems/meta-octavo-osd32mp1) to add support for Octavo dev boards on top of ST’s ecosystem.
Best,
Neeraj
Judy,
You will need to change the device tree in order to enable the SPI flash functionality. https://github.com/RobertCNelson/dtb-rebuilder provides a good way to do custom device trees. SM-RED’s device tree can be found here: https://github.com/octavosystems/OSD335x-Device-Tree/tree/master.
Please take a look at https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Kernel/Kernel_Drivers/SPI.html for additional information. Example implementation from ICEV2 board: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-icev2-common.dtsi#L233
Best,
Neeraj
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