RISC OS on IGEPv2

...NDA…

Is this still the case now? The above references were early/mid 2009. This OMAP Power Management/SmartReflex doc was created in Oct 2009. (Arrived at via BeagleBoard mailing list thread )

I’ve just checked the latest TRM (spruf98f, if anyone wants to upgrade from an older version), and in the Global_Reg_PRM register map it still says “This information is not available in public domain” for the address range where the SmartReflex registers lie.

Now for me to check all the bits of documentation they’ve revised for this new edition of the TRM ;)

Now for me to check all the bits of documentation they’ve revised for this new edition of the TRM ;)

A maemo developer (or at least forum contributor) says “use SPRUF98D instead of SPRUF98F ”. There may be stuff missing other than the USB OTG registers referred to. It’d be helpful if they had changelogs/diffs for documentation!

Interesting. I did spot a few bits of the TRM that had been rewritten, but didn’t think of checking the USB sections. Good thing I keep copies of all the old docs. (Although it did look like spruf98d was still available for those that want it)

Jeffrey, do you still have the email response I forwarded you concerning the graphics accelerator (stating that we should ask TI for the required information)? Maybe you could ask for that, too in case you get an answer to the SmartReflex question.

Yes, I should still have that mail somewhere. I’ll see how things go with the SmartReflex, then try digging a bit deeper for the SGX docs :)

A maemo developer (or at least forum contributor) says “use SPRUF98D instead of SPRUF98F ”. There may be stuff missing other than the USB OTG registers referred to.

Wow – that guy’s right. What used to be a 107 page chapter is now a 20 page chapter! Hopefully that’s just a temporary mistake and not an indication of Mentor getting stroppy (As far as I can tell the OMAP docs contained the only publicly available documentation for the MUSB controller).

Jeffrey,

Any joy with smartreflex?

Not yet, no. TI got back to me and said to contact one of their distributors in the UK, which I haven’t got round to doing yet. After reading some of Next To Nobody’s posts about his troubles trying to get documentation I’m a bit worried that they’re just sending me on a wild goose chase.

If I get stuck then I can always try asking on the beagleboard group – hopefully there’ll be someone there who has their head screwed on and can reveal how open/closed the documentation is and what hoops need to be jumped through in order to obtain it!

Could you email me the details of your request Jeffrey? I’ll make a similar request and see if a concerted effort yields more results?

Also we could probably reverse engineer something that works from the Linux driver as a stopgap?

One final thing… looks like the IGEPv2 patches made it into mainstream linux kernel this week. Yay!

Could you email me the details of your request Jeffrey? I’ll make a similar request and see if a concerted effort yields more results?

Sure, I’ll send it to you tonight.

Also we could probably reverse engineer something that works from the Linux driver as a stopgap?

We could try – although it would obviously be something that’s easiest for you to do since you’re in the best position to test whether it works!

How did your SmartReflex-less kernel build go?

Thanks for that info Jeffrey,

Havent managed to do the linux build yet. Too busy with one thing or another.

I have also emailed requesting the smartreflex and powervr NDA details. Lets see if that helps move matters.

Stephen, how is the network driver doing ? If you are happy with it, are you going to release the source ?

Driver works perfectly when it starts. Which is 1 in 3 for me. I have some bug somewhere with startup that i need track down. Once I have that done i’ll release the source.

If you want a binary update let me know.

A binary would not help me as I have a Devkit board. I was hoping I might be able to piggy back off your hard work and try to get a driver for the DM9000 working.

Which NIC does the Devkit have? if its the SMSC911X then Jeffreys work to do the GPMC setup in the HAL should mean my driver will work. If its not that chip i recommend starting from EtherUSB which has the sources available and which is what my driver is based on.

http://effarig.co.uk/riscos/

DM9000.

If its not that chip i recommend starting from EtherUSB which has the sources available

Therin lies the problem, as it is in a strange undecipherable language called “C”. If it was nice friendly assembler, I could probably make the changes. I have already setup the chip using an assembler module and can access registers ETC

With your version, it would require fewer changes and I would be more likly to understand it, as in theory I would only have to change the bits that talk to the chip.

my code is also in C, and looks like EtherUSB with all the other modules removed. Im not a fan of doing things in assembler.

The actual module i looks alot like the Asix AX88172 driver. I’m not prepared to give out the source until i have sorted the module startup bug. The IRQ code is the only difference and i basically used the code path that Jeffrey pasted in this forum a few pages back.

Jeffrey,

So far no reponse to my emails. Have you done any better?

Nope. I’ll try one more company and then try moaning on the newsgroup.

Been trying to track down my bug.

However DDT does not seem to be 32 bit compatible. Has anyone managed to get DDT running on the later ARMs?

If it’s a recent (i.e. ARMv7-safe) version of the C tools then it will probably run. However a few weeks ago Ben let me know that the CPU emulation that DDT uses for debugging/single-stepping through code hasn’t yet been updated for any of the new instructions. But I guess that if you’re using the default compiler settings then CC will have produced code that targets all RISC OS machines (i.e. only uses ARMv2/v3 instructions), so in theory you shouldn’t have any problems.

On the SmartReflex front – I’ve just sent a message off to DigiKey, after spotting that they actually have a data sheet/application note request form on their site. This is hopefully a sign that they’re able to provide people with confidential documents instead of just publicly available ones.

Ok thats interesting. How do i bully the DDT into running? I have the latest compiler toolchain 5.68.

I’ve been getting a consistent error.

Internal Error: abort on data transfer at &FC03EEE0.

(always the same address)

I’m going a little nuts trying to figure out whats wrong. I’m wondering if i have an unhandled interrupt source or something.

If i run EtherUSB just before my module it all works fine. If i run mine alone it fails. There is some code at FC03EEE0 before i run my module. (My module and EtherUSB share all the SWI and handler base numbers so that is probably why, but i cant see anything obvious different)

*modules shows The utilitymodule is at FC01E7D8 with PCI at FC03F188

when my modules loads its at 2039D4D4.

Ideas anyone? im going a little crazy.

Ok thats interesting. How do i bully the DDT into running? I have the latest compiler toolchain 5.68.

I’ve only used DDT once, so my best advice is to read the chapter about it in the DDE manual that came with the tools (Although if your manual is anything like mine, it’s horribly out of date and suggests that DDT is only any good for 26-bit code)

Also I’m not actually sure that DDT supports debugging of modules!

There is some code at FC03EEE0 before i run my module.

Good – the 4MB at FC000000 is the ROM image :)

My module and EtherUSB share all the SWI and handler base numbers so that is probably why, but i cant see anything obvious different.

I hope you’re not trying to run both of them at the same time if they share SWI base numbers! Try setting bits 18 & 19 of the SWI chunk number, that’ll move it into the group of SWIs reserved for user applications (i.e. you won’t clash with any SWIs that have been officially registered; see PRM pages 1-26/1-27 for details). Or, just send in an allocation request to ROOL (Although you’d obviously have to wait a while for a reply)

Ideas anyone? im going a little crazy.

The good news is that it’s crashing in the UtilityModule, which is one of the easiest modules to get debugging information for. Assuming you’ve built this ROM image yourself (if not, it’s probably a good idea to build one and use that), go into RiscOS.Sources.Kernel and run the MkRom script (note: to get the environment variables set up right you’ll at least have had to load !Builder and select the OMAP3 build directory and environment). That script should produce a ‘GPA’ file containing the addresses of all the symbols and source lines. For me, this pinpoints FC03EEE0 as being at line 431 of s/AMBControl/memmap, which sounds like a rather bad place to crash (hopefully it won’t be so bad with your GPA file!)

The next step after that would be to make lots of use of the Debugger module to work out why the code’s crashing and what your code has got to do with it. The fact that it runs fine in some situations but not in others suggests it’s corrupting memory somewhere.

I wasnt trying to use the 2 modules at the same time. I just noticed that if etherusb was already loaded my module ran fine which is mighty odd.

I’d believe a memory corruption issue. i’ve been through the code a few times and i’m stumped as to where it could be though.

I might try building the module with the gcc toolchain to see if i get the same behaviour. After seeing the issues with 64 bit numbers i dont have 100% confidence in the norcroft compiler.

Will report back.