[orocle]

Ignore my question… I just found that you don’t bring out the hsync pin for the tft controller.

Also,

You recommend using a SPI display, and that is an awful alternative that you shouldn’t be recommending especially when the product you are selling is specifically intended for it.

HSYNC is available in two pins(PC6 and PI10) and you didn’t bring any of those two out???, what a FAILURE. This makes the BRK paperweight because the beauty of this device is that it has a Linux kernel for displaying information, coupled with the QT Framework and an M4 core for real-time.

HUGE DISAPPOINTMENT!

[orocle]

A SPI display is an awful alternative that you shouldn’t be recommending especially when the product you are selling is specifically intended for it.

HSYNC is available in two pins(PC6 and PI10) and you didn’t bring any of those two out???, what a FAILURE. This makes the BRK paperweight because the beauty of this device is that it has a Linux kernel for displaying information, coupled with the QT Framework and an M4 core for real-time.

HUGE DISAPPOINTMENT!

• This reply was modified 3 years, 4 months ago by orocle.
• This reply was modified 3 years, 4 months ago by orocle.

[orocle]

Just checked your production image and the three spi devices are shown there, so it must be somthing in the kernel build and or device tree that differs from your image. But anyhow, the production image is good enough for now, and hopefully I won’t need to build the Kernel.

It would be of great help if Octavio publishs the entire enrironment that produces your production image, as it sits on your computers, sdk, sources and divices trees, patched and all. Perhaps a VM of some sort.

Anyhow if you have some insight in the above, that be great, otherwise no worries.

[orocle]

@Neeraj Dantu, thank you. I didn’t specify the issue.

The issue is that there are no SPI devices under /sys/class/spidev or /sys/class/spi_master, therefore there are no spi devices under /dev.

I can see the device tree has spi2,spi4 and spi6 speficied with the correct pin mux and enabled. So why are they not being registered? Also, lsmod, shows the following, notice there are no devices(used by) in spi_stm32 module.

root@stm32mp1:/sys/class# lsmod
Module Size Used by
cfg80211 557056 0
spi_stm32 24576 0
sch_fq_codel 20480 2
ipv6 442368 40
nf_defrag_ipv6 20480 1 ipv6

[orocle]

hmm.. no answer.

Is anyone using SPI ports on the linux side?

Any advice from the Octavo team on how to proceeed?

Thank you!

[orocle]

Thank you @Eshtaartha. I appreciate your recommendation.

[orocle]

While it is clearly apparent which board and image are in question from the prior posts, here it is again.

OSD32MP1-BRK and OSD32MP1-BRK OpenSTLinux. No DK2 whatsoever.

Why would I be looking here for DK2 information? And this is a sincere question not rhetorical.

Thank you

[orocle]

Hi Greg,

Another improvement to this tutorial would be a process flow similar to the one below, which is probably wrong, but it gives a person an idea of the parts to all this. For example, there is no information that the patch files need to applied prior to compiling and that the patch files add the default device tree which seems to not be the min_config from cubeMX.

I now get a new set of errors while compiling and I suspect it is because the patch files are broken, or some other step is missing. See the error below.

Considering that a custom device tree is likely critical to working with this part, it should be easier. 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). This is a really nice part, it would a shame not to have something like this be standard. I will eventually be able to align all this and keep it as a close secret, but that doesn’t help anyone else after.

Any help is appreciated.

Thank you

– PROCESS FLOW –
1. Get CubeMx and install it
2. Get the device tree and open it from CubeMX, may need to migrate
3. Generate from CubeMX
4. Get developer package and extract it
5. Copy the generated files from CubeMX to each image
6. Get the patch files and copy them to each image, replacing prior makefile.sdk
7. Apply the patches – see howto file in each image
8. Compile each image – see howto file in each image

– 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

• This reply was modified 3 years, 11 months ago by orocle.
• This reply was modified 3 years, 11 months ago by orocle.

[orocle]

Hi Greg,

There are no relevant updates to what I describe here. The problem is when flashing the SD with the starter pack as it is described in section 5 of the tutorial doesn’t work. If I understand correctly it is because the starter pack needs to be patched first with the files from https://github.com/octavosystems/BRK_Developer_Package_patches which includes a compilation step which seems to be loosely described.

My question is why can’t you patch and compile the starter pack and make that available instead so that one can upgrade the Developer Package?

The primary goal of this exercise a custom device tree. It seems that there are a few unnecessary steps or information as to why they are necessary.

Thank you

“Flashing and upgrading SD card
Before you can use the custom device tree files generated from CubeMX, you need to first flash a SD card with OpenSTLinux Starter Package. ” …

“Step 1: Flashing the SD Card

To use a custom Device Tree, it is necessary to upgrade OpenSTLinux Starter Package (openstlinux-20-06-24 at the time of writing) to Developer Package. To do this, please complete the following steps:” …

[Author]

Posts