Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32MP157F-DK Build Failing #8

Open
blakefuller3 opened this issue Jan 31, 2023 · 12 comments
Open

STM32MP157F-DK Build Failing #8

blakefuller3 opened this issue Jan 31, 2023 · 12 comments

Comments

@blakefuller3
Copy link

Hello, I'm building with the STM32MP157F-DK as the target, but the latest commit references the U-Boot submodule which doesn't include DTS files for STM32MP147F (only earlier silicon versions). I see in your latest actions you have successfully built for the xx157F target, but I can't manually update the U-Boot commit version successfully.

Can you provide any insight in how you successfully targeted xx157F?

@blakefuller3
Copy link
Author

Hello, I've got the build working now with some slight modifications to the submodule git commits and the uboot and linux scripts. I've attached my raw git diff. Perhaps I'm building incorrectly?

My application uses a USB camera and an application running GTK. When I try to execute my application I find that X11 (which GTK defaults to) can't find the display (HDMI or the dev kit DSI display) using the command xrandr. I've also tried with WLR-randr but it has the same issue of not being to open the display. Both give the output Can't open display, however both DSI and HDMI can output the terminal and respond to modetest so I know (at least the phy and driver layer) of the DTS is configured correctly.

Now I have also been able to build the image from your source with the modifications I've posted and have tried a number of attempts to get the display to work, such as building the gcnano library by modifying your script then installing the galcore kernal object, modifying boot args, modifying the DTS to disable DSI and only use HDMI. None of these have have resulted in Wayland or X11 detect the display.

Can you suggest any reason for this? Thank you for your work in maintaining this repository!

STM32MP1 Git Diff BFuller 06Feb23.txt

@cvetaevvitaliy
Copy link
Owner

Example run Weston via console:

XDG_RUNTIME_DIR=/tmp weston --tty=2

For run weston as service need to create initd or systemd startup script

Example script for initd
https://github.com/cvetaevvitaliy/buildroot-external/blob/master/board/stmicroelectronics/stm32mp157/sodimm2-overlay/etc/init.d/S20weston

Example script for systemd
https://gist.github.com/rkitover/715c1ba5fb1dc3cbb1f1a3ff51a103f2

@cvetaevvitaliy
Copy link
Owner

For X11 example config file /etc/X11/xorg.conf

Section "Device"
 Identifier "ST Accelerated Framebuffer Device"
 Driver "vivante"
 Option "fbdev" "/dev/fb1"
 Option "vivante_fbdev" "/dev/fb1"
 Option "SyncDraw" "false"
EndSection

@blakefuller3
Copy link
Author

blakefuller3 commented Mar 31, 2023

Running xinit still fails unfortunately. See attached log from X11. I have galcore installed, but I can't see how the X11 server is supposed to find the Vivante kernel object or driver. Attached is the output of lsmod.

Xorg.0.log
lsmod.log

@cvetaevvitaliy
Copy link
Owner

This is an example of a configuration file.

Pleas refer to the official Xorg documentation

https://www.x.org/wiki/UserDocumentation/

@blakefuller3
Copy link
Author

I believe the issue is with how galcore is installed. I’ve updated your script build-linux.sh script to build galcore.ko from the gcnano source (the steps are commented out in the source in the repo) and manually installing the kernel object with insmod. Can you clarify how the vivante driver should be built and installed?

@cvetaevvitaliy
Copy link
Owner

Need to apply this patch '00005-add-at-f-stm32mp157a-sodimm2-mx.patch' for kernel

@blakefuller3
Copy link
Author

Okay I will try that. That patch (and others) were failing during build.

@cvetaevvitaliy
Copy link
Owner

Of course, this patch was made for the specific kernel version specified in the submodule, if you have a different version, you get build error

@blakefuller3
Copy link
Author

Okay I think this is the issue. To build for -157F I needed to update u-boot and arm-tf submodule to a newer branch as the branch in this repo doesn’t include the DTS and other files for -157F

@cvetaevvitaliy
Copy link
Owner

Okay I think this is the issue. To build for -157F I needed to update u-boot and arm-tf submodule to a newer branch as the branch in this repo doesn’t include the DTS and other files for -157F

you can do it, update the submodules and make a pull request, so others can use it too. thanks for the help.

@karu2003
Copy link

does not work any more . old patches. :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants