Rpi model and version information
21 posts, 7 voices
John Rickman (71)
646 posts
|
Under Raspbian you can discover information about a Rasberry Pi model number and revision number using the Cat command – cat /proc/cpuinfo |
John Williams (567)
768 posts
|
May I refer you to the work of Gareth Locke in the thread at at: csa.programmer.Simple platform detectionwhich may soon come to fruition of some sort! Sorry I can’t be more precise, but I’ve done my New Year clearout! |
Chris Hall (132)
3558 posts
|
Is there an equivalent or something similar under RISC OS? Yes, see Archive 24.2 p.15 – the utility !ScreenHelp shows this info. Get it from !Store. |
|
John Rickman (71)
646 posts
|
see Archive 24.2 p.15 – the utility !ScreenHelp Thanks John for the link and thanks Chris – your utility does the business. |
|
Chris Hall (132)
3558 posts
|
ScreenHelp has been updated to version 1.62 and now includes OS_ReadSysInfo,9. On the Titanium it now reports (via the !Help application) as below:
The code to produce this is rather awkward (it makes a compelling case for not trying to poke the hardware to see what it is and just to test for features you need via an API or RMEnsure) and I’m sure could be improved: |
Steve Pampling (1551)
8172 posts
|
I think it perhaps makes a case for something to be included in the default builds that pops out the full system description in a text file that people with problems can post along with enquiries on the forum. It would save a lot of questions, particularly to new users, about what machine tpe/OS revision/etc they are running. |
|
Chris Hall (132)
3558 posts
|
I think it perhaps makes a case for something to be included in the default builds that pops out the full system description in a text file that people with problems can post That was one of my motivations – I could ask a user to download !ScrHelp from !Store and post a particular result. |
Rick Murray (539)
13850 posts
|
Aha, you’re calling BCMSupport to get that. It’s a shame ReadSysInfo doesn’t. I ask, because ScrHelp doesn’t work for me (never has – I think I mentioned this about a billion years ago). The screen blanks for a few seconds (fiddling with the mode?) and then comes back but the app is ‘frozen’. Thirty seconds later, still frozen. It can be task killed. Firmware dates from 21st September 2017, OS is 5.23 (low vector) built on the 21st March 2017.
In the DDE’s Extras directory is a TaskObey file called MachineInfo that reports some stuff: This isn’t to say ScrHelp isn’t needed, they report their own different things and together can give a report on most 1 of the status of the machine. 1 I notice that nothing appears to report on the status of the network configuration. ;-) |
|
Rick Murray (539)
13850 posts
|
Hmmm… Probably not a great idea to get into posting a reply when something’s in the oven. Fish and chips ready in 25 minutes, I finally made it to the kitchen after 38. |
|
Rick Murray (539)
13850 posts
|
Just worked through the code progressively addings in It’s failing in the block that reads the EDID information. Putting cmdline/txt = disable_mode_changes config/txt = # NOTE: Pi is connected to analogue LCD using HDMI-VGA adaptor. # NOTE: Last fiddled with: 2018/11/29 hdmi_force_hotplug=1 hdmi_blanking=1 hdmi_drive=2 hdmi_force_edid_audio=1 # Set 1280x1024@75Hz mode (usual LCD monitor) hdmi_group=2 hdmi_mode=36 # 35 is 1280x1024@60Hz # If using the other monitor... 1440x900@60Hz #hdmi_mode=47 # Analogue video options - 16:9 PAL # sdtv_mode=2 # sdtv_aspect=3 # For the Pi2, slow down the minimum rate arm_freq_min=400 fake_vsync_isr=1 disable_overscan=1 framebuffer_swap=0 framebuffer_ignore_alpha=1 framebuffer_align=0x100000 init_emmc_clock=100000000 gpu_mem=32 ramfsfile=CMOS ramfsaddr=0x508000 kernel=RISCZP.IMG #kernel=RISCOSZP.NEW Hmm, if I’m running the ZP kernel, then it’s not my build, and it’s high vector? I wonder when I switched? I don’t remember at all. Most likely I switched to check some software didn’t create pain, and never switched back. ;-) |
|
Rick Murray (539)
13850 posts
|
Just did Abridged version: # Exported from ScrModes 0.63 file_format:1 monitor_title:C17-7 DPMS_state:3 # Mode: 640 x 480 @ 75Hz startmode mode_name:640 x 480 x_res:640 y_res:480 pixel_rate:31500 h_timings:64,120,0,640,0,16 v_timings:3,16,0,480,0,1 sync_pol:3 endmode # Mode: 640 x 480 @ 60Hz startmode mode_name:640 x 480 x_res:640 y_res:480 pixel_rate:25175 h_timings:96,40,8,640,8,8 v_timings:2,25,8,480,8,2 sync_pol:3 endmode # Mode: 720 x 400 @ 70Hz # Mode: 720 x 480 @ 60Hz # Mode: 720 x 480 @ 60Hz # Mode: 800 x 600 @ 75Hz # Mode: 800 x 600 @ 60Hz # Mode: 1024 x 768 @ 75Hz # Mode: 1024 x 768 @ 60Hz # Mode: 1280 x 720 @ 60Hz # Mode: 1280 x 720 @ 50Hz # Mode: 1280 x 1024 @ 75Hz # Mode: 1280 x 1024 @ 60Hz startmode mode_name:1280 x 1024 x_res:1280 y_res:1024 pixel_rate:108000 h_timings:112,248,0,1280,0,48 v_timings:3,38,0,1024,0,1 sync_pol:0 endmode # Mode: 1280 x 1024 @ 60Hz startmode mode_name:1280 x 1024 x_res:1280 y_res:1024 pixel_rate:108000 h_timings:112,248,0,1280,0,48 v_timings:3,38,0,1024,0,1 sync_pol:0 endmode Yes, there are two identical 1280×1024 60Hz definitions. No idea why. I used OS_ScreenMode 2 to dump the mode definitions known about, and it shows “1280 × 1024” three times – that’ll be the 75Hz one and the two 60Hz ones. &t;aside> Hmm, 1280×720 50Hz. Implies that when I hooked my satellite receiver to the monitor (via HDMI-VGA adaptor) and told it to output 720p, it should have worked. I wonder which bit was unhappy with that scenario? </aside> <more aside> Of course, EDID doesn’t necessarily describe all of the capabilities of a monitor. This monitor actually responds to and generates a picture when my composite video to VGA adaptor is outputting 1400×1050, 1440×900, 1600×1200 (*}, 1680×1050, and 1920×1200 (*). The two marked ‘*’ appear to generate an image, put stick an “OUT OF RANGE” message centre screen. The other three? They just seem to work! </more aside> |
|
Rick Murray (539)
13850 posts
|
Note to self (save me looking it up again): >SYS "OS_ScreenMode", 2, 0, ,,,, 0, 0 TO ,, a%,,,, b%, c%
>PRINT a%, b%, c%
-39 0 -1516
>DIM x% 1516
>SYS "OS_ScreenMode", 2, 0, ,,,, x%, 1516
>PRINT ~x%
8F34
>PRINT ~1516
5EC
>*Save $._modedef 8F34 +5EC
|
Stuart Painting (5389)
714 posts
|
ScrHelp freezes on my machine in the same way, although in my case SaveModeFile shows duplicate mode entries for 1280×720@60Hz, which doesn’t correspond to the native resolution (1680×1050) so I’m at a loss to understand why they are duplicated. Of course this could be a giant red herring and ScrHelp is freezing for a totally unrelated reason… |
|
Rick Murray (539)
13850 posts
|
I’m sure it is – it ought to just evaluate to the same thing twice – but it was worth noting that it was happening since it appears twice in the MDF.
Unfortunately I don’t know what sort of information is being passed to/from the GPU to see about why it’s choking, only where as in which bit of code fails. |
|
Chris Hall (132)
3558 posts
|
Where did you find out what to pass to get the info from the GPU? Jeffrey Lee, I think. Yes here |
André Timmermans (100)
655 posts
|
EDID info usually contains info from multiple standards and extensions, and mode definitions can be found multiple times. Edit: I was wrong the issue is still present. |
|
Chris Hall (132)
3558 posts
|
I ask, because ScrHelp doesn’t work for me (never has – I think I mentioned this about a billion years ago). The screen blanks for a few seconds (fiddling with the mode?) and then comes back but the app is ‘frozen’. Thirty seconds later, still frozen. It can be task killed. I have improved the error trapping around EDID block decoding in version 1.63. Hopefully this should now work on Rick’s machine. I can confirm that this has taken me less than a billion years by quite a factor. |
|
Rick Murray (539)
13850 posts
|
Nope. :-( If you want to send me a version with some logging, I’ll be happy to run it. |
|
Chris Hall (132)
3558 posts
|
I have uploaded 1.64 which might work. |
|
Chris Hall (132)
3558 posts
|
Version 1.70 of ScrnHelp uploaded and available from !Store – this now shows EEPROM software date on Pi4 as well as boot drive and filesystem. It uses a bit of a kludge to get the EEPROM date as the magic number to use with BCMSupport_SendTempPropertyBuffer (which is the easiest method for using the mailbox property interface) is unknown. |
|
Chris Hall (132)
3558 posts
|
Version 1.72 of ScrnHelp uploaded and available from !Store. This now shows whether a Compute Module 4 has eMMc and/or WiFi fitted. Update: version 1.74 uploaded to fix bug in 1.72! |
