RISC OS on IGEPv2

Anyway to avoid having to type in

every time i boot the IGEP?

Ok.

static net_device_t* s_units[MODULE_MAX_UNITS]; //

this array does not get zero’d when defined. I missing something?

C doesn’t automatically initialise variables, arrays or structs. The contents are whatever was in that bit of memory last time (i.e. unpredictable). If you want it zeroed you will need to explicitly do this yourself with something like memset(s_units, 0, sizeof(s_uints)); The only time I would expect variables and arrays to get automatically initialised is if you are using a debugger which prefills variables with known patterns to trap the use of uninitialsied pointers etc.

static pointers are automatically initialized to NULL. See C99:TC3 6.7.8, §10:

Either my code is corrupting the memory or the Norcroft compiler does not adhere to the c99 spec.

Confirmed that gcc and icc initialise static pointer arrays. MSVC doesnt but it doesnt pretend to be a c99 compiler.

Maybe its time to ditch the Norcroft compiler.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void* s_unit[100];

int main(int argc, char** argv)
{
  for (int i=0; i< 100; i++)
    {
      printf("%08x\n", (unsigned int) s_unit[i]);
    }

  return 0;
}

A few more tests show that Norcroft does initialise static arrays correctly.

Stranger and stranger.

But it doesnt work for modules…

”....Modules that use any of the C99 library functions, long long variables or variable length arrays require the SharedCLibrary 5.43 or later to be loaded as explained in C99 features on page 72.”

-zM “appears” to fix this for me.

Definite progress made on the driver tonight.

Startup issue is gone but im seeing a few crashes which may be related to some of the debugging code i’ve inserted.

Anyway to avoid having to type in

*scsi *cpucompat *!boot

every time i boot the IGEP?

How old is the ROM image you’re using? I checked in some changes on the 22nd of April to allow automatic booting from devices which SCSIFS treats as floppies (e.g. USB sticks & card readers). For hard discs, I believe you’ll need to perform the change mentioned in this post.

-zM “appears” to fix this for me.

Yes, as you’ve discovered you need to tell it that you’re compiling a module otherwise very bad things will happen. I’m surprised the linker didn’t complain – I would have expected it to have knowledge of whether each object file had been compiled as module code or not.

Glad to hear you’re getting the problems sorted!

I wont have built a new ROM since the 10th of April. I had been meaning to ask if the publically available ROM image was up to date.

I’ll do an update and build fresh this weekend, will need to crank up the RPC for this.

Nothing from the linker except to say that it had stripped the debug symbols out.

oooooooh….

New shiny ROM. Autoboots. Thanks Jeffrey, that makes a huge difference to testing turnaround times.

is there anyway to get debug info from an irq handler? Could i output to the debug serial console somehow from the irq handler?

Stephen

SmartReflex update.

I have recompiled the linux kernel with the following options disabled and it seems to make no difference. Linux is stable booting whereas RISCOS isnt in the same thermal state.

CONFIG_OMAP_SMARTREFLEX

CONFIG_OMAP_RESET_CLOCKS

I’m going to try disabling a few more options and see if that makes any difference.

Jeffrey,

Dont know if this is any good to you but here is the config setup for the omap video section.

#
# Frame buffer hardware drivers
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_VRAM_SIZE=4
CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
# CONFIG_OMAP2_DSS_RFBI is not set
# CONFIG_OMAP2_DSS_VENC is not set
# CONFIG_OMAP2_DSS_SDI is not set
CONFIG_OMAP2_DSS_DSI=y
CONFIG_OMAP2_DSS_USE_DSI_PLL=y
# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=1

is there anyway to get debug info from an irq handler? Could i output to the debug serial console somehow from the irq handler?

Yes, the easiest way to get debug output is likely to be via the HAL_DebugTX HAL call. E.g. _swix(OS_Hardware,_IN(0)|_INR(8,9),char,0,EntryNo_HAL_DebugTX)

If you need something with higher throughput then you can log to a buffer in memory using DADebug. It doesn’t look like there’s a binary available to download anywhere, but the source is included in the OMAP3 ROM sources and it’s trivial to get it built into the ROM image (just uncomment the DADebug line in BuildSys.Components.ROOL.OMAP3)

I have recompiled the linux kernel with the following options disabled and it seems to make no difference. Linux is stable booting whereas RISCOS isnt in the same thermal state.

OK. I think I’ll try porting the Linux driver to RISC OS and see what happens.

Thanks for the debug output help. that works nice.

Let me explain what i’m seeing.

Since I changed my compiler options my irq_handler gets called but seems to get re-interrupted before completion over and over.

If I send a debug output with no format options right at the start of the irq handler then i see that on the console. However if i do vnsprint with even one int as a parameter the machine just seems to jam into a continuous cycle of interrupts not cleared. (I would prefer that RiscOS/HAL disables this irq when this situation arrises and prints a notice on the console to say so).

I wonder if the compiler options have slowed down my irq handler enough to cause problems?

Is there any good documentation on the irq cycle in RISCOS? It seems that the irq_handler is being called with interrupts enabled. I have looked over your dispc_irq_handler but I’m not making much sense of the cycle.

On another note. Unless this is already part of the OS i would not call a function to check if an irq is for the current process TestIRQ, the name is misleading. “Check” or something else would be better.

My irq setup and the irq_handler are at http://pastebin.com/mSdQDXcw if anyone can spot what the issue is.

void irq-routine(...)
{ static int busy=FALSE;
  if(busy) return 1;
  busy=TRUE;

and then before every return clear your busy flag. You could add an overrun counter to see if your if you did fix your problem later on.

Good luck,

Peter V

Your IRQ handler will be being entered with interrupts disabled, so something must be enabling them somewhere. I believe that screen output will re-enable interrupts, and I’ve also had problems with the DebugLib library where it seemed that using time-stamped debug output would enable interrupts. Also if your code triggers an abort before it’s able to service the interrupt then bad things almost certainly will happen.

(I would prefer that RiscOS/HAL disables this irq when this situation arrises and prints a notice on the console to say so).

There’s some code to do this in the HAL, it just isn’t enabled by default (I’m not sure why – I guess I had a reason!) First, check HAL.OMAP3.hdr.omap3530 and make sure that DebugInterrupts is enabled. Then in HAL.OMAP3.s.Interrupts enable the DebugDisablePrevious option.

Is there any good documentation on the irq cycle in RISCOS?

Not that I know of.

I have looked over your dispc_irq_handler but I’m not making much sense of the cycle.

I’m not surprised. It’s a bit convoluted because of the way it handles SYNCLOST/SYNCLOSTDIGITAL interrupts – whenever one is received it needs to reinitialise the video controller, the processing of which is split over several interrupts in order to avoid taking up too much CPU time.

Looking at your pastebin, it looks like this is the problem:

// cast private word to our device structure
ws_t *ws = pw;

Basically you’ve passed a pointer to one of your data structures to the IRQ handler, but for modules that use CMHG/cmunge you absolutely must pass the module’s private word pointer (the ‘pw’ pointer that’s passed to module_init). The reason behind this is that the assembler veneers that CMHG/cmunge generate assume that the module’s private word pointer is in R12 on entry, so that they can use the contents of pw to set up some magic values on the stack that the shared C library requires. The veneers also load the pointer to the block of memory that the compiler placed all the read-write data in (global variables, etc.)

So to fix your problems:

1. Change all your OS_Claim, OS_Release, OS_ClaimDeviceVector, OS_ReleaseDeviceVector, etc. calls to pass the module’s private word instead of arbitrary data
2. Since the private word pointer was the only way you had of passing data to your routines, you’ll now have to find some other way of doing it. Global variables will work, but are obviously of limited use if you’re trying to make the code cope with multiple concurrent devices. In that case you might want to investigate using the callx library (see RiscOS.Sources.Lib.callx)

Ok i’ll give this a try. Thanks Jeffrey.

I’m very confused by not being able to have the irq return a user defined “piece of data”. I’m totally happy with having to pass the module_pw when proding the irq code but it seems a bit mental that you can’t tack your own data into the mix to identify the device you want to service.

Oh well. I’ll let you know how i get on.

I’m very confused by not being able to have the irq return a user defined “piece of data”. I’m totally happy with having to pass the module_pw when proding the irq code but it seems a bit mental that you can’t tack your own data into the mix to identify the device you want to service.

Yes, I guess it’s just a side-effect of the fact that the C compiler was developed after the OS. Although exactly why CMHG/cmunge don’t have built-in callx-style functionality is anyone’s guess.

Thats fixed it.

All working! I’m going to refactor a little bit of the code but anyone who wants a binary version for now that works with the IGEP either post a note here or email me at sleary at vavi dot co dot uk

:)

Release 0.2

<a href="http://www.vavi.co.uk/~sleary/EtherS02.zip">http://www.vavi.co.uk/~sleary/EtherS02.zip</a>

[Edit: stupid site wont let me escape a tilde.]

Oooh! The AM/DM37x TRM is now out. Why is this interesting? Apart from letting me take a look at all the bits that need changing to support the -xM, it also looks like they forgot to remove the SmartReflex register descriptions & usage documentation from the PRCM chapter (Either that or they’ve decided that they aren’t under NDA any more, which would be a bit odd since the latest OMAP TRM from just a couple of weeks ago still omits them). Plus there’s documentation about the SmartReflex module, which I never even knew existed before (so I guess there’s a chance it simply didn’t exist before). Needless to say I’ll be keeping hold of this edition of the TRM! (even though it now looks like SmartReflex isn’t the magic that makes the IGEP work)

For those who are interested, it looks like the 1GHz ARM clock speed isn’t the only improvement the AM/DM37x chips have over OMAP3. This page has a nice summary of the differences – L1 caches have doubled in size to 32KB each, and the L3 interconnect & SDRAM controllers now run at 200MHz instead of 166MHz, which is sure to be of help. Plus the SDMA controller now supports linked lists, which will make it a hell of a lot easier for RISC OS to use for complex transfers.