+- Freeplaytech Forum (https://forum.freeplaytech.com)
+-- Forum: Freeplay Zero / Freeplay CM3 / Game Pie Advance (https://forum.freeplaytech.com/forumdisplay.php?fid=24)
+--- Forum: Freeplay Zero/CM3 (AKA GPA) Hardware (https://forum.freeplaytech.com/forumdisplay.php?fid=25)
+--- Thread: Freeplay CM4 (/showthread.php?tid=5392)
RE: Freeplay CM4 - Flavor - 07-16-2022
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 audio (loads snd_bcm2835)
dtparam=audio=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.
RE: Freeplay CM4 - Flavor - 07-16-2022
(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
RE: Freeplay CM4 - smoscar01 - 07-16-2022
Thanks for cleaning up the config.txt file!
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.The one I had compiled a while back had a line commented out where `DISPLAY_FLIP_ORIENTATION_IN_SOFTWARE` was set, as per the instructions in this thread: https://forum.freeplaytech.com/showthread.php?tid=4989.
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, quittingIt 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?
RE: Freeplay CM4 - Flavor - 07-16-2022
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.
RE: Freeplay CM4 - Flavor - 07-16-2022
Maybe try without HDMI for a bit, and use these lines to force the HDMI to 320x240. See if that helps anything.
hdmi_group=2
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
hdmi_force_hotplug=1
RE: Freeplay CM4 - Flavor - 07-16-2022
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 ...
cd ~/Freeplay
git clone https://github.com/TheFlav/rpi-fbcp.git
cd rpi-fbcp
./install.sh
sudo reboot
RE: Freeplay CM4 - Flavor - 07-16-2022
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.
Read about tuning performance at https://github.com/juj/fbcp-ili9341/blob/master/README.md#tuning-performance
You will likely want to change the SPI CDIV scaler to maybe 8. That might still be fast enough and not overdrive the SPI.
RE: Freeplay CM4 - Flavor - 07-16-2022
OR, if you don't want to recompile, you MIGHT be able to set this in the config.txt as a test.
core_freq=400
RE: Freeplay CM4 - smoscar01 - 07-16-2022
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?
Code:
pi@retropie:~ $ ./bcmstat.sh
Config: v0.5.5, args "", priority lowest (+19)
Board: 4 x ARMv7 cores available, ondemand governor (Pi1 Unknown rev 1.0, BCM2838 SoC with 1GB RAM by Sony UK)
Memory: 1024MB (split 948MB ARM, 76MB GPU) plus 100MB Swap
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 600MHz | 250MHz | 0MHz | 3180MHz |
Max Freq: | 1500MHz | 500MHz | 500MHz | 3180MHz |
Voltages: | 0, 0.8500V | 0, 1.2000V |
Other: temp_limit=85
Firmware: Dec 1 2021 15:01:54, version 71bd3109023a0c8575585ba87cbb374d2eeb038f (clean) (release) (start)
Codecs: H264 MJPG PCM
Booted: Fri Jul 15 23:21:51 2022
Time ARM Core H264 Core Temp (Max) IRQ/s RX B/s TX B/s
======== ======= ======= ======= =============== ====== =========== ===========
23:26:44 1500Mhz 500Mhz 0Mhz 66.22C (67.68C) 18,962 0 0
23:26:46 800Mhz 267Mhz 0Mhz 64.76C (67.68C) 15,649 0 0
23:26:48 800Mhz 267Mhz 0Mhz 66.22C (67.68C) 15,414 0 0
23:26:50 800Mhz 267Mhz 0Mhz 65.73C (67.68C) 15,428 0 0
23:26:52 900Mhz 300Mhz 0Mhz 64.76C (67.68C) 15,220 0 0
23:26:54 900Mhz 300Mhz 0Mhz 67.19C (67.68C) 15,305 0 0
23:26:56 900Mhz 300Mhz 0Mhz 66.22C (67.68C) 15,454 0 0
23:26:58 800Mhz 267Mhz 0Mhz 66.22C (67.68C) 15,376 0 0
23:27:00 900Mhz 300Mhz 0Mhz 66.70C (67.68C) 15,513 0 0
23:27:02 800Mhz 267Mhz 0Mhz 65.24C (67.68C) 15,346 0 0
23:27:05 800Mhz 267Mhz 0Mhz 66.70C (67.68C) 15,439 0 0Changing 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:
Code:
bcm_host_get_peripheral_address: 0xfe000000, bcm_host_get_peripheral_size: 25165824, bcm_host_get_sdram_address: 0xc0000000
BCM core speed: current: 250000000hz, max turbo: 400000000hz. SPI CDIV: 6, SPI max frequency: 66666667hzAnd bcmstat now shows a ~consistent 244MHz core speed:
Code:
pi@retropie:~ $ ./bcmstat.sh
Config: v0.5.5, args "", priority lowest (+19)
Board: 4 x ARMv7 cores available, ondemand governor (Pi1 Unknown rev 1.0, BCM2838 SoC with 1GB RAM by Sony UK)
Memory: 1024MB (split 948MB ARM, 76MB GPU) plus 100MB Swap
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 600MHz | 250MHz | 0MHz | 3180MHz |
Max Freq: | 1500MHz | 400MHz | 500MHz | 3180MHz |
Voltages: | 0, 0.8500V | 0, 1.2000V |
Other: temp_limit=85
Firmware: Dec 1 2021 15:01:54, version 71bd3109023a0c8575585ba87cbb374d2eeb038f (clean) (release) (start)
Codecs: H264 MJPG PCM
Booted: Fri Jul 15 23:41:07 2022
Time ARM Core H264 Core Temp (Max) IRQ/s RX B/s TX B/s
======== ======= ======= ======= =============== ====== =========== ===========
23:46:21 1500Mhz 250Mhz 0Mhz 70.60C (70.60C) 17,549 0 0
23:46:24 800Mhz 244Mhz 0Mhz 70.60C (70.60C) 14,876 0 0
23:46:26 800Mhz 244Mhz 0Mhz 70.11C (70.60C) 14,622 0 0
23:46:28 800Mhz 244Mhz 0Mhz 70.11C (70.60C) 14,935 0 0
23:46:30 800Mhz 244Mhz 0Mhz 70.11C (70.60C) 14,647 0 0
23:46:32 800Mhz 244Mhz 0Mhz 69.63C (70.60C) 15,018 0 0Still 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?
RE: Freeplay CM4 - Flavor - 07-16-2022
Maybe forget all about bcmstat. The output from fbcp-ili9341 will show the speed, anyway.
So, at core_freq=400, it's working now?
Sound is a different issue, so let's make sure video is working.
Sound can be several things. It has to be set properly in the config.txt. It's that audremap thing, I think.
Then, it also needs to be set up properly in emulationstation. This can be tricky. Play with the settings in there to see if you can get audio.
ALSO, with audio, if you have HDMI connected, it could be trying to pump audio over HDMI.
You can try playing video files with omxplayer. I think you can test the output using alsa.
Maybe try running this commandline.
cd /home/pi/Freeplay
git clone https://github.com/TheFlav/Freeplay-Support.git
omxplayer /home/pi/Freeplay/Freeplay-Support/audiotest.mp4 -o alsa
Do you get video and audio from that?