Raspberry Pi 4 Thread - general discussion

[PeterO]

I was a little confused about the two mini HDMI ports vs one full size one,

FYI they are micro HDMI not mini HDMI.
PeterO

[jamesh]

Out of curiosity : do this new SoC integrates a RTC (with battery pin exposed) ?
It's not a request, I know it's not useful for almost users and for those who it's useful, there is plenty of third party boards out there. But sometimes it's just available on some SoC.

No.

[RaTTuS]

Out of curiosity : do this new SoC integrates a RTC (with battery pin exposed) ?

no
[edit]
JamesH beat me

[Brian Beuken]

When I change to hello_triangle demo to not bail out on a Pi 4, it hangs in the same eglCreateContext. Is there any way to get OpenGL ES/Dispmanx applications working on the Pi 4?

No it will need minor changes to the code. The good news is after the changes the code will run unchanged on earlier Pi's with fkms/kms enabled as well at other linux platforms that support kms/drm/mesa.

Can you be more specific on what changes are needed?

[PeterO]

When I change to hello_triangle demo to not bail out on a Pi 4, it hangs in the same eglCreateContext. Is there any way to get OpenGL ES/Dispmanx applications working on the Pi 4?

No it will need minor changes to the code. The good news is after the changes the code will run unchanged on earlier Pi's with fkms/kms enabled as well at other linux platforms that support kms/drm/mesa.

Can you be more specific on what changes are needed?

I'm just tidying up a working triangle2
PeterO

[alphixt]

Does new RPi v4 support SDHC UHS-x cards? Apparently that information is a secret because I can't find it in official paperwork.

I am trying to figure out similar information as to what all cards the RPi 4 is capable of running efficiently compared to it's predecessors. More information on its Micro SD Card improvements would be amazing.

[6by9]

Thanks for that. Very useful.
I constructed a `dpi_timings` from this and got: `dpi_timings=1024 1 48 96 144 600 0 3 10 11 0 0 0 60 0 49000000 3`.
Sadly, it doesn't work. Here's my thinking behind each parameter:

Code: Select all

1024  (horizontal pixels)   self-explanatory
1  (invert hsync)           I suppose this corresponds to "-hsync" in the cvt output. Negative sounds like it would be considered to be inverted?
48  (h front porch)         hsync_start-hdisplay (1072-1024 = 48)
96  (hsync pulse width)     hsync_end-hsync_start (1168-1072 = 96)
144  (h back porch)         htotal-hsync_end (1312-1168 = 144)

600  (vertical pixels)      self-explanatory
0  (invert vsync)           Corresponds to +vsync? See above.
3  (v front porch)          vsync_start-vdisplay (603-600 = 3)
10  (v sync pulse width)    vsync_end-vsync_start (613-603 = 10)
11  (v back porch)          vtotal-vsync_end (624-613 = 11)

0  (v sync offset a)        should be zero according to docs
0  (v sync offset b)        ditto
0  (pixel rep)              ditto
60  (frame rate)            self-explanatory
0  (interlaced)             zero according to docs
49000000  (pixel frequency) 49 MHz from cvt output. Makes sense and is within the range according to that datasheet.
3  (aspect ratio)           15/9 is the closest aspect ratio in the list. Actual aspect ratio is 128/75.

I tried all four combinations of inverted [hv]sync, but to no avail. Screen is still just black.
Is there anything obviously wrong with these values? Thanks!

I'll try and pull out the full timings that your hdmi_cvt line applies when I'm in the office tomorrow.

Having let the firmware do it's thing, I get out

Code: Select all

h_active_pixels = 1024 (0x400)
h_sync_polarity = 0 (HDMI_NEGATIVE_SYNC)
h_front_porch = 40 (0x28)
h_sync_pulse = 104 (0x68)
h_back_porch = 144 (0x90)
v_active_lines = 600 (0x258)
v_sync_polarity = 1 (HDMI_POSITIVE_SYNC)
v_front_porch = 3
v_sync_pulse = 7
v_back_porch = 14 (0xe)
v_sync_offset_a = 0
v_sync_offset_b = 0
pixel_rep = 0
frame_rate = 60 (0x3c)
interlaced = 0 (HDMI_NONINTERLACED)
pixel_freq = 49000000 (0x2ebae40)

So

Code: Select all

dpi_timing=1024 0 40 104 144 600 1 3 7 14 0 0 0 60 0 49000000 6

should be the equivalent.
You can actually do this for yourself. If you use hdmi_cvt= in config.txt, then "vcgencmd hdmi_cvt" or "vcgencmd hdmi_timings" will read back the current values (in the old scheme they also allow you to set the timings, but you're better off doing that through KMS now).

[solar3000]

The base RPi 4 B should have started off at 4 GB with a socket to add more.

I have a PC with a full AT motherboard running linux. I have installed 32 big ones in the 4 memory slots. When it's not running virrtualbox, it only uses less than 3 or 6 GB. And most of that is due to firefox bloat.

[solar3000]

I'm still waiting for pi 6. I demand the engineers get to work right away.

There are probably folks at RPT already thinking about the Pi6, while the Pi5 is probably already starting to be sketched out.

jamesh mentioned that they had been discussing the Pi6 a few days ago.

Ugh I missed it. I've been sick with the flu for a few days. Last time I check rpi's website, it was showing the wooden case.

[Brian Beuken]

No it will need minor changes to the code. The good news is after the changes the code will run unchanged on earlier Pi's with fkms/kms enabled as well at other linux platforms that support kms/drm/mesa.

Can you be more specific on what changes are needed?

I'm just tidying up a working triangle2
PeterO

Let me know how you get on, can't play with mine till the weekend.

[PeterO]

Can you be more specific on what changes are needed?

I'm just tidying up a working triangle2
PeterO

Let me know how you get on, can't play with mine till the weekend.

Keep an eye on the openGLES forum.

[RPIgoodSBC]

Congratulations on the new rpi-4B.
The hardware is very promising and I am sure in a short time the software will be up to the new hardware.

I have requested my new rpi-4B 2Gb RAM and I am waiting to receive it.

My wish list for the new rpi-4B is:

1) Latest version of Chromium running youtube in fullscreen [email protected] in a completely fluid way without loss of frames, in the rpi-3B+ only Chromium-65 is working fine on fullscreen 1080p.

2) Improvements in the graphics driver.Vlc at perfect fullscreen 4K is possible?

3) USB-3 booting.

4) Full kodi support inside raspbian.

5) Underclock options in raspi-config to minimize overheating.

6) To be able to choose dual boot at the beginning (something similar to syslinux choose system to boot with countdown timer is possible? ) from SD or USB.

After many years at last a raspberry pi without bottlenecks on the data buses.

Thanks for your hard and good work.

[jbudd]

WiFi MAC address changes

My older Pis up to Pi 3B all have MAC addresses B8:27:EB:xx:xx:xx (Raspberry Pi Foundation)
The Pi4 has DC:A6:32:xx:xx:xx (Raspberry Pi Trading)

What's the significance of this change - apart from making the Pi a bit harder to spot in IpScan24?

[RaTTuS]

WiFi MAC address changes

My older Pis up to Pi 3B all have MAC addresses B8:27:EB:xx:xx:xx (Raspberry Pi Foundation)
The Pi4 has DC:A6:32:xx:xx:xx (Raspberry Pi Trading)

What's the significance of this change - apart from making the Pi a bit harder to spot in IpScan24?

a different Ethernet chip.. ?

[DirkS]

WiFi MAC address changes

My older Pis up to Pi 3B all have MAC addresses B8:27:EB:xx:xx:xx (Raspberry Pi Foundation)
The Pi4 has DC:A6:32:xx:xx:xx (Raspberry Pi Trading)

What's the significance of this change - apart from making the Pi a bit harder to spot in IpScan24?

Better chance of *not* getting duplicate MAC addresses?
There's nothing secret to it, (see the first random internet resource I found at https://udger.com/resources/mac-address ... foundation) so I can't see why it would be harder to spot?

[Heater]

The first 6 digits of a MAC address make up the vendor code.

The Raspberry Pi Foundation and Raspberry Pi Trading are different vendors.

[jbudd]

a different Ethernet chip.. ?

This is WiFi - which I believe is the same chip as the Pi3

The Raspberry Pi Foundation and Raspberry Pi Trading are different vendors.

Yes, and I noticed someone (@jamesh maybe) made the point that the Pi4 development is thanks to Raspberry Pi Trading not Raspberry Pi Foundation. Just wondered why...

There's nothing secret to it, ... so I can't see why it would be harder to spot?

The latest version of IPScan24 knows that the older Pis are manufactured by Raspberry Pi Foundation, it doesn't give a manufacturer for the Pi4

[Andyroo]

On my iPad, Pi computers come up as Apple watches

I’ve pushed a note to the vendor - till they do an update I’m stuck with lots a watches in the house

[tomasf]

So

Code: Select all

dpi_timing=1024 0 40 104 144 600 1 3 7 14 0 0 0 60 0 49000000 6

should be the equivalent.
You can actually do this for yourself. If you use hdmi_cvt= in config.txt, then "vcgencmd hdmi_cvt" or "vcgencmd hdmi_timings" will read back the current values (in the old scheme they also allow you to set the timings, but you're better off doing that through KMS now).

Cool. Thanks for that. Unfortunately, the screen is still black using those timings. I checked using my oscilloscope, and the HSYNC and VSYNC signals look as expected on my Pi3+, but there's no signal at all on my Pi4B - the pins are at a constant high signal level.

Any other ideas? For reference, here's my current config.txt:

Code: Select all

dtoverlay=dpi24
enable_dpi_lcd=1
display_default_lcd=1

dpi_group=2
dpi_mode=87
dpi_output_format=0x6f005
dpi_timing=1024 0 40 104 144 600 1 3 7 14 0 0 0 60 0 49000000 6

#hdmi_cvt=1024 600 60 6 0 0 0
#hdmi_group=2
#hdmi_mode=73

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=128

[6by9]

Cool. Thanks for that. Unfortunately, the screen is still black using those timings. I checked using my oscilloscope, and the HSYNC and VSYNC signals look as expected on my Pi3+, but there's no signal at all on my Pi4B - the pins are at a constant high signal level.

Any other ideas? For reference, here's my current config.txt:

Code: Select all

dtoverlay=dpi24
enable_dpi_lcd=1
display_default_lcd=1

dpi_group=2
dpi_mode=87
dpi_output_format=0x6f005
dpi_timing=1024 0 40 104 144 600 1 3 7 14 0 0 0 60 0 49000000 6

#hdmi_cvt=1024 600 60 6 0 0 0
#hdmi_group=2
#hdmi_mode=73

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=128

I wonder if the pin muxing isn't right.
Please check with "raspi-gpio get" that GPIOs 0-27 are all set to alt2 for the DPI function.
You can achieve the same as "dtoverlay=dpi24" by doing "gpio=0-27=a2".

If that doesn't work, please start a new thread (with links to these comments) as detailed diagnostics in a "general discussion" thread is going to get lost.

[tomasf]

I wonder if the pin muxing isn't right.
Please check with "raspi-gpio get" that GPIOs 0-27 are all set to alt2 for the DPI function.
You can achieve the same as "dtoverlay=dpi24" by doing "gpio=0-27=a2".

Yay! That did it! The screen didn't look quite right with that dpi_timing line, but it turns out that old hdmi_cvt line still works with the correct gpio settings in place. Thank you!

[BlindDevelopment]

Has there been any indication as to when the BCM2711 Peripherals Specification will be released, or more specifically the memory addresses of the GPIO registers to be access via C/C++?

Haven't found anything myself, but screen reading sometimes misses things.

Cheers!

[M5]

I'm sure that I am missing somthng. But my old fathfull samsung 21" LCD TV with HDMI output that worked will with my RPi B up till my B3+ had no problem showing 1080p seems to have failed me. as the 1080p out put of HDMI0 on my new RPi 4 B is bugger than the screen. so the top, bottom & both sides are off the screen.

I tried to edit the settings in the config.txt file in the boot directory. But this only seems to work in text mode.

Please can any one help?

Thank you every one in advance

Brian (M5)

Can you turn off overscan on the TV? We are still working on overscan for FKMS.

You could revert back to legacy graphics mode until that is sort out. Edit config.txt and comment out the fkms line in the Pi4 section to see if that helps. Not sure what other effects that might have, but should work.

I have disabled the following lines in the config.txt




[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
#dtoverlay=vc4-fkms-v3d
#max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=512
#hdmi_enable_4k=1

It is working fine now . Tryed the RPi 4 with a 50" Hitachi and had no porblems at all.

Thank you for your help

[6by9]

Can you turn off overscan on the TV? We are still working on overscan for FKMS.

You could revert back to legacy graphics mode until that is sort out. Edit config.txt and comment out the fkms line in the Pi4 section to see if that helps. Not sure what other effects that might have, but should work.

I have disabled the following lines in the config.txt

Code: Select all

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
#dtoverlay=vc4-fkms-v3d
#max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=512
#hdmi_enable_4k=1

It is working fine now . Tryed the RPi 4 with a 50" Hitachi and had no porblems at all.

Thank you for your help

You now have no 3D hardware enabled.

There is no mainline Linux kernel support for overscan in 4.19. It's just been merged with 5.2. We are trying to backport it at present.

[Ashe]

The HDMI hardware does not support YCbCr420. So for 4Kp60 deep colour YCbCr422 is the only option

Just reading through all these posts earlier about HDMI and YCbCr420. Does all this mean my SDR 4K TV won't work with the Pi 4 at 4K60? This is what NVIDIA Control Panel shows for it.