Eshtaartha Basu
Forum Replies Created
Hello mhdzr@inaoe.edu.mx
Unfortunately, CubeMX sets the default “Device Tree Root Location” path to the directory in which the CubeMX project was originally created. At the moment, manual updates to the path is not allowed.
You can get over this by doing the following:
1. Download the OSD32MP15x_MinimalConfig.zip from the OSD32MP1 CubeMX app note page and extract it.
2. Download and install the latest CubeMX software on your Ubuntu machine.
3. File > Load Project > OSD32MP157C-512M-BAA_MinimalConfig.ioc (Migrate the project to latest version if necessary)
4. File > Save Project As > Choose new folder or directory of your choice on your PCNOTE: Once the project is saved to a new location, the “Device Tree Root Location” will automatically get updated to that new location on your PC.
5. Generate Code
Hello ryanclem,
The pinmux for MMC0 interface is initialized in U-Boot under mux.c file – https://github.com/RobertCNelson/u-boot/blob/master/board/ti/am335x/mux.c. This should be sufficient.
Neither TI nor Beagleboard community reinitialize MMC0 again as part of their Linux device trees. Octavo System’s device trees for OSD3358-SM-RED are based on device trees developed by TI for the AM335x processor. Also, as listed under Tables 4-36, 4-37 and 4-38 of AM335x datasheet (https://www.ti.com/lit/ds/symlink/am3354.pdf?ts=1609958701723&ref_url=https%253A%252F%252Fwww.google.com%252F), MMC0 peripheral can claim only one set of pins when enabled whereas MMC1 and MMC2 interfaces can choose from several sets of pins.
We have not tested the behavior OSD335x with MMC0 pinmux reinitialized as part of Linux DT.
Discussion on the same matter can also be found on TI’s official forum below:
https://e2e.ti.com/support/processors/f/791/t/668324
https://e2e.ti.com/support/processors/f/791/t/758096?Linux-PROCESSOR-SDK-AM335X-Conversion-pinmux-tool-output-to-mux-c-for-u-boot (See Brad’s response at the end)
https://e2e.ti.com/support/processors/f/791/t/742464?AM3356-Configuration-of-MMC0-pins-to-GPIO-mode
Attachments:
Hello todd_peterson,
From the error messages, it looks like you’re using BeagleBone image and DTC v4.19 but the latest release of Device Tree source files on our git are for kernel v4.14 (picture attached). The syntax errors you’re seeing are probably because of the version mismatch.
If you’re using an Octavo Systems device, we recommend using OSD3358-SM-RED Linux Image (https://octavosystems.com/files/osd3358-sm-red-linux-image/). You can use this image to make custom modifications to your device tree files and rebuild them. This will help you prevent errors.
NOTE: While downloading the dts files from our git, use the “tags” under “switch branches” drop down to choose the right tag that matches your kernel version.
You could also use Robert Nelson’s Device Tree Rebuilder to rebuild your dts files – https://github.com/RobertCNelson/dtb-rebuilder (choose the branch version that matches your kernel). More info on this is given under section 1.3 of our Device Tree App Note – https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/
Attachments:
Hello Orocle,
1. Why would I be looking here for DK2 information? And this is a sincere question not rhetorical.
[Octavo]: Sorry for the inconvenience.
The CubeMX Tutorial was first published in June 2019. At that time OSD32MP1-BRK was not yet available to the public. Hence, we chose a STM32MP15x platform (DK2) that was easily available as the platform for this tutorial.
The overall flow of configuring the device trees and the tools used (CubeMX, CubeProgrammer, OpenSTLinux SDK etc) are same
for both STM32MP15x and OSD32MP15x.CubeMX app note is intended to help customers become familiar with the overall flow of configuring device trees. We are currently working on a BRK specific version of CubeMX app note. We will release it soon.
2. I’ve followed the STM32MP1 CubeMX Tutorial for OSD32MP15x, and well it doesn’t work. I think it is because the
patching instructions aren’t included in the tutorial so you end up with something that doesn’t work.
“Error: Message from Embedded Flash Loader : mmc device 0 not found” This is likely because the missing
sdcard detect pin? among other things not compatible with DK2.[Octavo]: The OpenSTLinux Starter Package suggested in the tutorial is for DK2. The chip detect pins for DK2 and BRK boards
are different. The Flash Loader is unable to detect mmc0 because it is looking for chip detect signal on the wrong pin.To bring up OSD32MP1-BRK successfully, we recommend following the steps under section 5.2 of
BRK Getting Started Guide (https://octavosystems.com/app_notes/osd32mp1-brk-getting-started/).
We do provide OpenSTLinux and Debian options. Choose OpenSTLinux for this exercise.Note: In order to flash BRK using instructions from CubeMX tutorial, you need the BRK specific .tsv file and Device Tree files.
The correct .tsv file can be found under “Cube Programmer Support” here – https://github.com/octavosystems/BRK_Developer_Package_patches.
The BRK specific Device Tree binaries can be built after applying the given patches to OpenSTLinux Developer Package as described here – https://github.com/octavosystems/BRK_Developer_Package_patches.The patches actually take care of several steps described in the tutorial (thereby helping you skip them):
– Generating board specific device trees
– Placing the source device trees in respective directories in the developer environment
– Modifying makefiles suitably to account for the new device tree source files etc.3. – COMPILATION ERROR –
DTC arch/arm/dts/stm32mp157c-osd32mp1-brk.dtb
Error: arch/arm/dts/.stm32mp157c-osd32mp1-brk.dtb.pre.tmp:1017.1-7 Label or path optee not found
FATAL ERROR: Syntax error parsing input tree
scripts/Makefile.lib:308: recipe for target ‘arch/arm/dts/stm32mp157c-osd32mp1-brk.dtb’ failed[Octavo]: As mentioned in the “Requirements” table of https://github.com/octavosystems/BRK_Developer_Package_patches, the
patches require these specific versions of Developer Package, SDK, U-Boot etc. Please double check the version of your Developer
Package. Using v2.0.0 (instead of the latest version) should resolve the issue. You can find Dev Package v2.0.0 under section 2.1 of
ST Wiki’s Archives – https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package_-_Linux_kernel#Archives4. For example, I want to enable FDCAN2 because my application requires FDCAN1 and FDCAN2 and later I will need TFT configured.
It seems what is really a must is the source files already patch for osd32mp1 from the developer package and all one needs is
to generate the device tree from CubeMX and replace it for each image(TF-A,U-boot,Kernel).[Octavo]: As mentioned in the Caveats of CubeMX tutorial, CubeMX does not allow us to fully configure all peripherals through its GUI. For example, it does not support configuration of STPMIC1 PMIC or let us set chip detect GPIO pin for uSD card. Such settings require manual configuration and validation.
The output of CubeMX should be used as a starting point only if you’re building DT from scratch. Otherwise, you can use it as a reference.
If you want to enable FDCANx for BRK (for which DT is already provided), we recommend using the Device Tree generated by CubeMX as a reference to modify the provided Device Tree for BRK. You can copy/paste the FDCAN related nodes from CubeMX DT to BRK’s DT and set other tags/properties under “USER CODE” suitably (if necessary).Thank you for all the suggestions. We will make sure to capture and address all your concerns in the upcoming BRK specific CubeMX tutorial to ensure better development experience for other customers.
Please let us know if you have any other concerns.
Hello slisgrinder,
Based on your observations, it looks like your UARTx_Rx lines are not pulled up (internally or externally). UARTx_Rx lines have to be pulled up to avoid Break Condition (https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter#Break_condition). This is the reason your system is booting up fine when you connect Rx lines to +3v3 externally.
In case of RED board, we have pulled up UART0_RX pin internally by declaring pull up resistor in the RED device tree (screenshot attached). Check your device tree to make sure internal pull up is enabled on the UART0_Rx pin.
Attachments:
Hello Ericj92,
The source device tree files (.dts and .dtsi) for the RED board are available at https://github.com/octavosystems/OSD335x-Device-Tree. The properties of Ethernet controller are declared under “mac” node of “osd335x-sm.dtsi”.
If you’re using the RED board with official RED Debian image (https://octavosystems.com/files/osd3358-sm-red-linux-image/), no device tree mods should be necessary to get ethernet working.
Please provide more information as to what you’re trying to do. Are you using RED Debian on a custom board/design? If yes, it will be helpful if you can share boot log or dmesg.
