RISC OS on IGEPv2

Sent you an update.

Anyone on the test list needing support getting the driver up and running can catch me on #riscos on freenode. Nick is plasmab.

There are a few differences in the way Linux and RISC OS calculate the DSI PLL multipliers/divisors, along with a few differences in other places. I’m not sure which differences are significant and which ones aren’t. I’ve got some code which should result in the same PLL settings that Linux uses, but Norcroft seems to be completely broken when it comes to handling 64bit ints, so my code won’t run. I’m about to go away for a few days, but should anyone feel like trying to bash some sense into norcroft (or getting rid of the 64bit ints), the new code is below:

clock_divider calculate_dss_clock_divider(u32 pixel_rate)
{
typedef unsigned long long u64;
    clock_divider best;
    best.regm = 0;
    best.regn = -1;
    if(!pixel_rate)
    {
        return best;
    }
    pixel_rate = pixel_rate*2;
    u32 best_error = pixel_rate;
    /* Search for a satisfactory regn:
       - Provides Fint that's within range
    */
    clock_divider current;
    current.regn = 1; /* Current N(+1) */
    do
    {
        u32 Fint = hwconfig->sys_clk/current.regn;
        if((Fint >= 750000) && (Fint <= 2100000))
        {
            /* REGN is good; now try all the different REGM values */
            dprintf(("","regn=%d Fint=%d\n",current.regn-1,Fint));
            for(current.regm=1;current.regm<=REG_MAX(DSI_PLL_CONFIGURATION1_DSI_PLL_REGM);current.regm++)
            {
                u64 dsiphy=(((u64)hwconfig->sys_clk)*((u64)2)*((u64)current.regm))/((u64)current.regn);
                current.regm3 = (u32) (dsiphy/((u64)pixel_rate));
//                if(current.regm3>16)
//                    break;
//                if(current.regm3<1)
//                    continue;
                dprintf((""," regm=%d regm3=%d dsiphy=%d\n",current.regm,current.regm3-1,(int)(dsiphy/1000)));
                if((current.regm3>=1) && (current.regm3<=16))
                {
                    u32 error = abs(pixel_rate-(dsiphy/current.regm3));
                    if(error < best_error)
                    {
                        best_error = error;
                        best.regm = current.regm;
                        best.regn = current.regn-1;
                        best.regm3 = current.regm3-1;
                        dprintf((""," regm=%d regm3=%d dsiphy=%d err=%d\n",best.regm,best.regn,best.regm3,(int)(dsiphy/1000),best_error));
                        if(!error)
                            return best;
                    }
                }
            }
        }
    } while(++current.regn <= REG_MAX(DSI_PLL_CONFIGURATION1_DSI_PLL_REGN)+1);
    return best;
}

Note that I’ve added regm3 to the clock_divider struct; you’ll have to update dsi_pll_program_for_dispc to do the following instead of the ‘frequency on data lane’ stuff:

config1 |= div.regm3 << DSI_PLL_CONFIGURATION1_DSS_CLOCK_DIV_SHIFT;

Jeffrey, Could you email me your broken code (or just a zip of the folder everthing broken sits under) and i’ll take a crack at it.

OK; it looks like it’s only unsigned long longs that are broken. Signed ones seem to work OK (or at least in the minimal test I was putting together). So if you tidy up the above code and change u64 to s64 then it should work…

I tried this but it didnt seem to help. Admittedly i may have made the wrong mods to dsi.

i didnt see anything on the debug console other than the usual.

This is the modification i made to dsi.c. Everything seems to work fine, no debug output on the console, but the screen problem still continues.

        /* REGM3+1 = frequency on data lane/(pixel rate*2)
           REGM3+1 = (2*pixel rate*bpp)/(pixel rate*2*lDnes) = DSI_BPP/DSI_LANES */
        lcdconfig *config = &hwconfig->lcd_configs[current_lcd];
-       //config1 |= ((config->dsi_bpp/config->dsi_lanes)-1)<<DSI_PLL_CONFIGURATION1_DSS_CLOCK_DIV_SHIFT;
+       config1 |= div.regm3 << DSI_PLL_CONFIGURATION1_DSS_CLOCK_DIV_SHIFT;
        /* REGM4 unused, so leave as 0 */
        config1 |= 7<<DSI_PLL_CONFIGURATION1_DSIPROTO_CLOCK_DIV_SHIFT; /* TODO - EXPERIMENT - Sort out REGM4 */

WPB, Can i just ask.. what monitor settings do you have?

WPB, Can i just ask.. what monitor settings do you have?

I was using an MDF based on the one here, but now I generally don’t bother to switch from my configured AKF60 MDF. I’m running at 1024×768 @ 60Hz most of the time, though the display problems show up even at VGA resolutions! My monitor’s native is 1680×1050, but I’d have to drop down to around 45Hz for the OMAP to cope with that, and unfortunately my monitor doesn’t taken signals that slowly!

WPB,

I’ve started seeing my driver crash alot after init has been called. Happened after i changed some settings and saved my desktop.

I can work around it by running etherusb first but i dont have time to look into the problem this week. I leave for the wedding tomorrow and dont come back until next monday.

No worries. I’ll maybe try the EtherUSB fix. Right now, I’m fighting screen problems more than ever!

Have a great wedding!

I keep telling ya, just bang a FAN on it and no more screen problems, I know it is not the most proper solution. But isn’t that what all intel boxes do?

I keep telling ya, just bang a FAN on it and no more screen problems, I know it is not the most proper solution. But isn’t that what all intel boxes do?

Hi Thomas. Sorry, I didn’t mean to ignore you the first time you suggested this! Yes, I probably should do that. But I’m aiming to use this board as a portable solution, and any extra power is a bad thing. But for the time being (development), I guess a fan would help. Did you try running the diagnostic Jeffrey suggested to get a reading of your CPU temperature, by the way? It would be interesting to know what temperature it’s running at with the fan on…

I’m back now – so some time today or tomorrow I’ll hopefully have a new version of the video driver ready which will program the registers with the exact values Linux seems to use. If that doesn’t fix the video problems then I guess I’ll have to dig a bit deeper and try and spot anything else that’s different (e.g. the order registers are programmed, any delays waiting for things, etc.)

Maybe an idea for the heat problem. A small program that counts the wimp poll idle events. If it gets above a threshold (for example 200 polls/sec) it calls some low level function to put the processor to sleep for a short time and than try to get the wimp polls at 200 times/sec.

If that doesn’t fix the video problems then I guess I’ll have to dig a bit deeper

I have also noticed that, although when I don’t touch the machine it will sit happily with a stable screen for many hours on end, if some USB stick activity happens for any reason, that can send the screen flickering, too. Which again points to a DMA issue, I suppose.

Just to confirm, the BB doesn’t suffer from this, does it? So does that mean it’s a difference in the bootloader setups for the two boards, then? Since they both have an OMAP3530, everything else should be the same (until you hit the DVI framer?)...

Maybe an idea for the heat problem. A small program that counts the wimp poll idle events. If it gets above a threshold (for example 200 polls/sec) it calls some low level function to put the processor to sleep for a short time and than try to get the wimp polls at 200 times/sec.

The Portable module should do this already – although I can’t remember if I verified that the code in the Wimp to call it actually worked.

Just to confirm, the BB doesn’t suffer from this, does it? So does that mean it’s a difference in the bootloader setups for the two boards, then? Since they both have an OMAP3530, everything else should be the same (until you hit the DVI framer?)...

I’ve never seen my beagleboard suffer from the problem, and the only complaints I’ve seen have been from IGEP owners. So it could be u-boot, it could be some hardware bug introduced with a new OMAP revision, it could be some problem with the IGEP boards, or it could be a combination of all three.

Something I just realised that I’ve missed is that there are interrupts for FIFO underflows – so if I add some code to log those then it will hopefully provide some further insight into what’s happening (the driver currently only prints something when it receives a synclost interrupt – and although it looks like a synclost interrupt can be caused by FIFO underflows, I think some underflows can be recovered from without generating the synclost interrupt)

If it is a FIFO underflow then the only thing I can think of is the SDRAM controller setup – AFAIK the video FIFO settings are now fine, and the SDRAM controller is the only subsystem that’s able to control the relative priority of video/CPU/SDMA/USB/etc. memory accesses. Unfortunately I haven’t looked at the TRM long enough to work out how to properly configure the priority levels, and I have a feeling the default settings (which U-Boot and Linux are unlikely to change) would give video the highest priority anyway!

Hi folks,

Back from a lovely wedding in sunny spain. I’ll grab the latest code and build it all tonight.

Back from a lovely wedding in sunny spain.

Hope it went off without a hitch!!! (Sorry, I’ve been dying to say that for ages!)

I’ve uploaded a ROM image containing a tweaked video driver (plus the updated source) – http://www.phlamethrower.co.uk/misc2/riscos.zip

This version of the driver aims to try and match the values that Linux uses when programming the hardware. There are also a couple of other fixes I’ve made, so with any luck one or all of them will fix the IGEP video issues.

Relevant changes are as follows:

• dispc.c lines 238, 342 – Now sets the FIFO preload values to 256 bytes instead of using the values suggested in the TRM (Linux doesn’t touch the FIFO preload values, so unless I’ve missed something the default of 256 should be getting used)
• dispc.c 512 – Now uses a DISPC_POL_FREQ value of 0, which seems to match the value used by Linux. I’m not sure whether the AC bias fields are relevant when you use the RFBI in bypass mode (which is what the various OMAP boards use for their DVI output), so I’m not sure whether setting those fields to zero would be relevant or not. Otherwise the only other effect this has (for DVI output) is the loss of control over the H/V sync polarity.
• dispc.c 542 – Enabled the FIFO underflow & OCPERROR interrupts. At the moment the code will just log their occurence to the serial port, so make sure you’ve got a serial cable connected to watch the debug messages.
• dispc.c 221, 325, graphicsv.c 276 – After enabling the extra interrupts I found that we were getting OCPERROR interrupts on boot because the graphics overlay was being enabled before the DMA base address was being set. This fixes that.
• dsi.c 100 – It looks like we were enabling clocks to the DSI module when we didn’t need to. The DSI clocks are now kept off, like with Linux.
• dss.c, dss_reset() – Reworked a bit to ensure the VENC clocks are on before the reset, and to disable them again after the reset is complete (keeping them off until they’re needed matches Linux’s behaviour). We also enable automatic gating of the DISPC functional clocks, but I’d be surprised if that fixes the problems (all it should do is help conserve power)
• dss.c, calculate_dss_clock_divider() – Rewritten to ignore all the stuff the manual says about the data lane frequency. This matches the behaviour of Linux (I think the data lane frequency stuff is only relevant when using the DSI module for output). This version of the algorithm is better than the one I posted a couple of days ago – it now does far less work and produces more accurate results for the trickier rates like 25.175MHz. It also matches the behaviour of Linux by trying to generate a DSI clock of 48MHz (although now that the DSI clocks are left off I’m not sure how relevant this is)

So if the IGEP owners could try out the new ROM and report their experiences then that would be good. In particular, if it does fix all the display problems, it would be helpful if you could play around with the changes listed above that are marked EXPERIMENT to see which ones are/aren’t significant – I’d prefer to understand the problem than to rely on just mimicing the mysterious workings of the Linux driver! And if these changes don’t fix anything then there are still a few more I can try making (e.g. Linux seems to enable FIFO merging, which would be a big help if it turns out that FIFO undeflows are the cause of the problems)

I’ve also made a few fixes to venc.c which make PAL output work. Although I’m not sure the encoder gets programmed properly since it keeps throwing up SYNCLOSTDIGITAL interrupts (so for the moment I just disable that IRQ when using PAL output). I’ve also updated the wiki with better steps for enabling TV-out, should any Beagle/DevKit owners feel like trying it out and reporting back on whether it works or not. My monitor seems to detect them as NTSC & PAL signals correctly, and a quick and dirty test in BASIC suggests they’re using the right refresh rates, but quite a lot of the image seems to be being cropped. I’m not sure if this is just a problem with my monitor or a sign that we just need the ability to specify safe zones/centering options (at the moment the overlays will just be aligned to the top-left, and cropped if they are bigger than 720×480/720×576; it’ll be easy to see the extents if you switch into BASIC and change the screen background colour)

Jeffrey,

Perfecto i think. 20 mins of hammering and no glitches (browsing web and playing a video over the lan). See what everyone else says but i think you cracked it. I havent had much time to test things this week as i’ve been doing other projects but I should get back to fixing up the lan driver shortly.

Sorry to be the bringer of bad news, but I’m still getting glitches. Initially it seemed quite a bit better, but actually I think it’s about the same as before. It’s hard to quantify of course. The thing that tripped it up first off was when a non-multitasking error window popped up (I was trying to run !Verma – which doesn’t work – so that I could report the error message to the author). That made the display flash out a few times. Then I tried playing an ogg file via !DigitalCD (which works, and the audio doesn’t skip a beat even when the screen’s flickering). It’s an interesting test because it causes intermittent reading from the USB stick. That didn’t seem to bother the screen too much. But dragging a few windows around then made it glitch again, usually in time with the USB stick accesses (that I can see because of an LED on the stick).

Anyway, that’s just an initial ‘impression’ of what’s going on. Jeffrey, thanks a lot for looking into this and for all the work you’re doing. I hope it bears fruit in the end!

Have you tried checking the serial output to see if any FIFO underflow errors are being reported? (IIRC it’ll just show up as a message like “OMAPVideo: dispc_irq: Cause XXXXXXXX”)

Also, just in case there’s something “special” about your IGEP that makes the driver misbehave, can you please provide a copy of the *videoregs output so I can make sure everything’s being programmed with sensible values.

Also – are you using the USB host port or the OTG port? I’ve just realised that I haven’t tried using the OTG port since writing the new video driver. It’s possible the differing implementations could cause problems (the EHCIDriver transfers data by using the EHCI controller’s builtin DMA controller, but the MUSBDriver currently does everything using the CPU)

I have only ever used the host port. I didnt think the OTG port was supported on RiscOS.