Okay, first of all, I went through your config.txt and cleaned up a LOT of stuff. I think this will work better for you. Some stuff I just totally deleted, and you may want to put some things back in (if you need them) once you get things working. Maybe just make a copy of the current one and then paste this as config.txt.
Code:
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
dtoverlay=gpio-poweroff,gpiopin=21,active_low
# BEGIN FREEPLAY MODS
framebuffer_width=320
framebuffer_height=240
hdmi_force_hotplug=1 #these HDMI lines will try to set up 1024x768 (you can remove them if you have problems playing via HDMI)
HDMI_FORCE_MODE=1
hdmi_group=2
hdmi_mode=16
hdmi_drive=1 #Normal DVI mode (No sound) (2 for HDMI with sound)
#this next one is NOT for use with the fbcp-ili9341, only the generic/simple/slow fbcp
#dtoverlay=waveshare32b,speed=80000000,fps=60,rotate=270
dtoverlay=audremap,swap_lr=on
dtparam=i2c1_baudrate=400000 #makes a big speed difference
#use the newer "i2c1” instead of deprecated “i2c1-bcm2708”
#dtoverlay=i2c1-bcm2708,sda1_pin=44,scl1_pin=45,pin_func=6,combine=off
dtoverlay=i2c1,pins_44_45=1,combine=off
# Disable the ACT LED on the Pi Zero.
dtparam=act_led_trigger=none
dtparam=act_led_activelow=on
audio_pwm_mode=2
dtparam=watchdog=on # Enabling watchdog.
Notice that waveshare32b is commented out. Don't use that with the fbcp-ili9341. It could be your problem. I'll respond to your newest message in a bit, smoscar01.
(07-15-2022, 02:02 PM)smoscar01 Wrote: Weird update:
...
Could this be something fixable by reducing the speed in the dtoverlay?
Can DMA be configured/disabled through freeplayfbcp.cfg? or would I need to recompile all of them?
I touched on this in the previous reply. fbcp-ili9341 compiles in all its SPI settings (like speed, etc.). It doesn't need the waveshare32b line in the config.txt.
You should be able to use https://github.com/TheFlav/rpi-fbcp and waveshare32b-fp.dtbo. That would be a good exercise/test, but it won't be as fast/optimized as fbcp-ili9341.
If you use fbcp-ili9341, read the INSTALLATION section at https://github.com/juj/fbcp-ili9341
It talks about making sure to REMOVE lines like
dtoverlay=waveshare32b and dtparam=spi=on from your config.txt
When using this new config file I'm able to run the FreeplayILI9341 options without them throwing the DMA collision error, the program even outputs that it is resetting DMA channels for use`. I'm sometimes getting random issues with these options where only random lines are drawn on all over the screen and the images are rotated 90 degrees, it seems to be swapping the widht/height as per the initial output:
Code:
pi@retropie:~/Freeplay/FreeplayILI9341 $ sudo ./fbcpFilled
bcm_host_get_peripheral_address: 0xfe000000, bcm_host_get_peripheral_size: 25165824, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 233333333hz, max turbo: 500000000hz. SPI CDIV: 6, SPI max frequency: 83333333hz
Allocated DMA channel 5
Allocated DMA channel 1
Enabling DMA channels Tx:5 and Rx:1
DMA hardware register file is at ptr: 0xb5349000, using DMA TX channel: 5 and DMA RX channel: 1
DMA hardware TX channel register file is at ptr: 0xb5349500, DMA RX channel register file is at ptr: 0xb5349100
Resetting DMA channels for use
DMA all set up
Initializing display
Resetting display at reset GPIO pin 27
Creating SPI task thread
InitSPI done
DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE: Swapping width/height to update display in portrait mode to minimize tearing.
Relevant source display area size with overscan cropped away: 768x1024.
Source GPU display is 768x1024. Output SPI display is 240x320 with a drawable area of 240x320. Applying scaling factor horiz=0.31x & vert=0.31x, xOffset: 0, yOffset: 0, scaledWidth: 240, scaledHeight: 320
Creating dispmanX resource of size 240x320 (aspect ratio=0.750000).
GPU grab rectangle is offset x=0,y=0, size w=240xh=320, aspect ratio=0.750000
All initialized, now running main loop...
^CSignal SIGINT(2) received, quitting
Quit.
This custom version sets the drawable area to 320x240 instead of 240x320 like the FreeplayILI9341 but there's still a lot of artifacts on the screen.
Its output is this:
Code:
pi@retropie:~ $ sudo ./fbcpFilledN64
bcm_host_get_peripheral_address: 0xfe000000, bcm_host_get_peripheral_size: 25165824, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 300000000hz, max turbo: 500000000hz. SPI CDIV: 6, SPI max frequency: 83333333hz
Initializing display
Resetting display at reset GPIO pin 27
Creating SPI task thread
InitSPI done
Relevant source display area size with overscan cropped away: 1024x768.
Source GPU display is 1024x768. Output SPI display is 320x240 with a drawable area of 320x240. Applying scaling factor horiz=0.31x & vert=0.31x, xOffset: 0, yOffset: 0, scaledWidth: 320, scaledHeight: 240
Creating dispmanX resource of size 320x240 (aspect ratio=1.333333).
GPU grab rectangle is offset x=0,y=0, size w=320xh=240, aspect ratio=1.333333
All initialized, now running main loop...
^CSignal SIGINT(2) received, quitting
It seems as if they were trying to draw additional empty lines of pixels on the screen. I noticed both display different BCM core speeds, perhaps the timing to read the pixel lines is incorrect?
Are you always booting it up with the HDMI connected to your monitor? Try turning it all off, disconnecting HDMI, and then booting it up and run your test.
By the way, what sort of HDMI screen do you have? Is it capable of 1024x768? Does it register as a landscape or a portrait mode?
I kinda feel like this is getting weirder and weirder. Like, it shouldn't be this difficult, and I'm wondering if there is something else that's running or configured differently that's tripping things up.
Also, did you try the one at https://github.com/TheFlav/rpi-fbcp
It should be really simple, and it might give a good baseline to see if it just works. You'd have to add this line back in, to use it.
dtoverlay=waveshare32b,speed=80000000,fps=60,rotate=270
In theory, you could just edit the config.txt and ...
I am digging a bit more. I think the CM4 is perhaps running at a core frequency of 500MHz
See what https://github.com/MilhouseVH/bcmstat tells you about the frequencies. Oh, I see that your pasted output above shows it at 500000000Hz with "SPI CDIV: 6, SPI max frequency: 83333333hz" That's likely too fast.
Anyway, I think the Pi CM3 runs at 400MHz.
fbcp-ili9341 uses a scaler to run the SPI communication off that clock. We would now be running the SPI at 1.25x speed if we don't recompile with a different scaler.
07-16-2022, 09:06 AM (This post was last modified: 07-16-2022, 09:07 AM by smoscar01.)
tldr; I am getting an image now but the journey has just begun (not getting audio out of it )
Thank you so much, Flavor! So many options to test
The first one about using https://github.com/TheFlav/rpi-fbcp and waveshare32b-fp.dtbo is the one that was set up by default when I ran the Full_install.sh script. Unfortunately that just shows a white screen both when executed by the service or manually in the terminal.
I don't have the hdmi plugged in anymore, I only connect it when I need to share a picture here. It is just a random 5 inch raspberry pi monitor I have. From what I can see in its EDID, it does support 1024x768 and it registers as landscape.
Tested forcing the resolution to 320x240 from the config file as suggested, with the dtoverlay for waveshare commented out to test the custom binary but the same weird lines are shown on the display. Then tried uncommenting the waveshare dtoverlay and keep forcing the 320x240 resolution to test that with the default TheFlav/rpi-fbcp binary. Rebooted but still nothing shows up on the screen.
Haven't gone through the entire bcmstat script but it seems like the CM4 is not supported, and I'm not sure if I'm reading this right but it seems to say the core (or one of them at least) is running at 267MHz or 300Mhz. That doesn't sound right does it?
Changing the `core_freq=400` did not change anything when testing with the default TheFlav/rpi-fbcp binary and the waveshare dtoverlay enabled. But it did work when disabling the overlay and using my custom binary (or any of the ones in FreeplayILI9341). They now shows the following 2 lines:
Still reading through juj's repo but are there any consequences on using core_freq=400 vs compiling binaries set to a particular speed?
Also, I am not getting any audio out of either the speaker nor the headphone jack and dmesg shows `bcm2835_audio bcm2835_audio: card created with 4 channels`, is it time for me to start throwing things into the config.txt that were removed?
Like, it shouldn't be this difficult, and I'm wondering if there is something else that's running or configured differently that's tripping things up.
