RPi B+, 2B & 3B
Reg (3412) 21 posts |
I hope to target my project to one of the three ‘B’ systems from Raspberry Pi. Before I go crazy and spend all the company money I want to make sure we can get what we need. I read somewhere that the VSync in RISC OS on the RPi might be faked and not related to the actual video frame output. Is this correct for all the ‘B’ boards, or just some, or has it been fixed recently? The official RPi touchscreen connects the touch controller output to I2C-0, which the GPU firmware takes control of. Can RISC OS successfully interact with the GPU to get the touches? Or would I need to cut those wires and redirect them to I2C-1 on the GPIO pin matrix? The latest incarnation of the touchscreen uses the FT5426 chip so if I do redirect the wires then can RISC OS talk to that? Or is using the RPi a really bad idea with RISC OS? |
Glen Walker (2585) 469 posts |
Can’t really answer most of your questions, however, I would say that the Raspberry Pi platform has brought a lot of us new users to RISC OS – I use Pi’s exclusively (B+ is my main RISC OS desktop, my Zero was my favourite (need to get a new SSD adapter for it)—have also used a 2 and 3B with mixed successes in the past). Depends a lot on your needs and budget and while I would love to have something like a Titanium based computer to run RISC OS (ideally in a much smaller form factor) in reality the Pi family represent the best value entry point into using RISC OS. So, to answer that question, no its not a really bad idea in fact its a really good idea! …or were you asking “should I run Linux on my Pi instead?”…in which case it really depends on:
General rule of thumb: RISC OS will run faster but is harder to develop on (in the sense that there are fewer resources to draw upon on the Internet) and Linux will have better support for newer technology (e.g., WiFi). |
Rick Murray (539) 13351 posts |
Hard to answer without knowing what you are trying to achieve beyond “something to do with tagged video frames”. With a better idea of the intended purpose, it’s hard to answer. |
Reg (3412) 21 posts |
I basically have three options open to me now.
All three are possible with my current team. And indeed we already have a prototype working on bare metal code, but the flexibility is too low for expansion, and we have currently faked a few things just to get it working, so it needs a lot of work to bring it to production. My first alternate choice would be RISC OS over Linux (aka Raspberian) because it is ‘simpler’ with less bloat. The license fee of ten quid per unit is acceptable. But we want to be sure that support for newer devices is available. So I guess the FT5426 chip is kind of a test case here. And to see if the faked VSync is now a non-issue. |
Clive Semmens (2335) 3110 posts |
For general purposes, RISCOS on the Pi is brilliant. Whether it meets your specific requirement I’m not sure – that is, I don’t know whether VSync is faked or not. I think I understand more or less what you’re up to, and I’m not entirely convinced it would affect your legal problem even if it IS faked – nothing can get at the image in the frame between you creating it and the GPU issuing it to the monitor, as long as you don’t poll the WIMP. |
Reg (3412) 21 posts |
Yeah, I probably shouldn’t have put the last question. That will be hard for someone else to answer. But I am interested in the touch question and the faked VSync question. |
Clive Semmens (2335) 3110 posts |
Ah – yes – if “faked” meant a frame as sent to the monitor was the top part of one frame you’d created and the bottom of the next one, that would be a problem, I can see that. |
Rick Murray (539) 13351 posts |
In your CONFIG.TXT file, do: fake_vsync_isr=1 And then RISC OS will receive VSyncs from the GPU. Otherwise, it would just hang off TickerV and generate a false VSync every other tick (50Hz). Here’s the code in BCMVideo: https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Video/HWSupport/BCMVideo/s/BCMVideo?rev=1.38#l530 It is worth remembering that the Pi was designed using the BCM283x chip, which itself was intended as a media playback device. As such, the primary heart of the chip is the GPU. It’s that which gets the machine running and handles the boot (don’t take my word for it, try disassembling BOOTCODE.BIN and/or START.ELF – that’s not ARM code!). The slave device is the ARM. RISC OS treats the screen as a basic framebuffer. The GPU deals with translating the framebuffer contents to match the screen. The idea of the graphics chip being subservient to the processor is turned on its head when it comes to the Pi! RISC OS is flexible with how it deals with video. It can either switch mode/resolution and inform the GPU of the new video timings (behaving like traditional graphics hardware); or it can run in the original manner which was that the GPU is locked to a specific resolution (such as the native resolution of your display) and everything else is rescaled on the fly by the GPU.
Not strictly true. Depending on how the display is generated, it wouldn’t be too hard to do something like:
If the sprite update is fast enough (at least as fast as VSync), this could happen without the user ever noticing, yet something is in between the frame creation and the frame display. Don’t look down on RISC OS for this. Bluray discs are designed to be encrypted from disc media to television (HDCP), and look at how much good that was in the long run. Legal people are good at Thou Shalt (Not) without taking into account that reality is often different. If data is moving around, it can be got at. The DVD decrypter is small enough to print on a shirt or mug, and fast enough that it can run inline to read a VOB file and spit out decoded data to a video viewer program to display in realtime. The question would be – firstly is such a thing viable, and secondly is the machine accessible? Limiting access to the hardware is the first stage. If you get the touch device working, you could in theory air-gap the device so there’s no connection to the outside world. |
David Feugey (2125) 2687 posts |
RISC OS can almost be seen as bare metal with a toolbox.
If you don’t plan to modify RISC OS (and keep these modifications for you), it’s only 3£ per unit. |
Jon Abbott (1421) 2592 posts |
This was originally due to a restriction in the kernel blob and was resolved years ago. As Rick states fake_vsync_isr=1 in CONFIG.TXT will pass the GPU VSync through to the host OS.
RISCOS communicates with the GPU through the kernel blob, so provided there’s a method for accessing what you need it could be coded. RISCOS provides functions to map I/O space in, so provided you know the physical address of the device you can map it in and code your own touch screen driver.
Reading between the lines, you’re coding something that needs to be secure. RISCOS is not considered a secure OS, so if security is a factor a Unix derivative is probably more suitable. |
Rick Murray (539) 13351 posts |
Which begs the question1: what does Linux do if there’s no fake_vsync_isr? Can it read the real VSync from the GPU? Does it make up something? Or does it not concern itself at all with this, leaving it up to the video driver blob to sync updates to the screen? 1 FWIW, I know I’m using that phrase incorrectly. |
Reg (3412) 21 posts |
Then that is even more acceptable :)
It isn’t really relevant to my questions, but since you mention it: we don’t need a secure OS. The hardware connections are not accessible to untrusted officers (except for the touch screen). Our client assures us that things like secure boot and code signing are irrelevant, so we don’t argue with them.
I was kind of hoping the OS would do that for us. That was kind of the whole point of the OS. But this is not a show stopper though, the driver would be relatively simple. |
Jeffrey Lee (213) 6044 posts |
As mentioned by Rick, putting fake_vsync_isr=1 in config.txt will ensure RISC OS is able to get a VSync interrupt from the GPU. The reason it’s “fake” is because it isn’t the true VSync signal – it’s an extra interrupt which the GPU generates in software during the VSync period. However, one thing to bear in mind is that (to ease some compatibility issues with older software and other hardware), on the Pi version of RISC OS the VSync event that e.g. OS_Byte 19 waits for will actually occur (roughly) in the middle of the frame (there are some annoying timing issues with when the GPU will allow you to change the screen base address or palette, and “delaying” the VSync until the middle of the frame helps avoid them). If you use multiple screen banks (preferably triple-buffered) then you shouldn’t have to worry about any tearing effects.
Yes. There’s a block of memory which the firmware uses as a (read-only) softcopy of the FT5426 registers. Under RISC OS there’ll be a HAL device which you can scan for which will then tell you the address of the buffer. I don’t have time to go into the full details of this, but there’s some docs and a BASIC example here for finding the SPI HAL devices. If you change the first parameter of the OS_Hardware call from &0405 to &0602 then it should find the touchscreen device (which I think should only be present if you have a touchscreen connected) You can also use the BCMSupport module to get/set the buffer address via the GPU mailbox interface (which might be an easier way of getting going if you already had some bare-metal code for touch input), but if you’re starting from scratch it’s probably best to just use the HAL device that’s already been created. |