RISC OS on IGEPv2

cmunge encrypts and compresses code.

Not entirely true – in RISC OS land, if someone’s talking about cmunge they’re usually talking about the cmunge that’s supplied with GCCSDK, which is a free clone of CMHG.

Sorted. Interrupts working.

I have a minor TX issue but i can sort that quickly and get a very fast driver out to beta testers by the end of the week. I’m getting married over the next fortnight (did the legals yesterday) so I may drop off the radar until the 12th of April.

That’s great, Stephen. Good job. Sorry I haven’t been more responsive about the original beta you sent me. You caught me at a bad time. Anyway, I should be able to get back on to things a little this week, so if you want to send over the interrupt-driven version, I’ll give you some feedback.

Many congratulations on your upcoming marriage!

This isn’t exactly the right place for such a question, but I’ll ask it anyway! And I think I know the answer, too, but I just want to get some reactions ;)

If I have multiple addresses I’d like to map in that all lie in the same MiB of physical memory (I assume OS_Memory 13 and 14 and the like deal in MiB not MB if we’re being picky?), is it considered bad form to call OS_Memory 13 or 14 for each location, rather than working out the MiB that they’re in and mapping that in just once, and calculating offsets from the logical address returned?

(I assume OS_Memory 13 and 14 and the like deal in MiB not MB if we’re being picky?)

Yes, they deal in MiB. You’re unlikely to find a CPU where the MMU supports decimal mappings :)

is it considered bad form to call OS_Memory 13 or 14 for each location, rather than working out the MiB that they’re in and mapping that in just once, and calculating offsets from the logical address returned?

It’s probably best to call them multiple times, that way you don’t waste any address space if in future the calls are changed to use a smaller granularity (as it is now the calls will try and avoid mapping in the same 1MB multiple times, so you shouldn’t end up using up 1MB of space per call). Although in reality the <1MB that you’d be wasting pales in comparison to the 30MB that the OMAP HAL currently wastes ;)

It’s probably best to call them multiple times, that way you don’t waste any address space if in future the calls are changed to use a smaller granularity

Ah, I hadn’t thought of it like that. I was worrying about SWI overheads and (as you said) wasting a double mapping, but I was thinking the MMU probably tried not to map the same area in twice.

If in future the granularity gets smaller, it’d cause problems for code that assumes it’s mapped in a region of memory with a single call, wouldn’t it? Although I suppose the sort of amounts of memory we’re talking about wouldn’t be big enough to approach the granularity of the mapping scheme…would they?

Yes, they deal in MiB. You’re unlikely to find a CPU where the MMU supports decimal mappings :)

Quite! Would it be overly pedantic to update the documentation to say ‘MiB’ rather than ‘MB’? Is the intended meaning just so blindingly obvious to anyone with a clue that there’s no point!?

Jeffry, on the subject of smaller granularity, your changes to add the NIC into the HAL only calls for 256 bytes in the Board_InitDevices_DevKit routine. The chip only has two registers to access, but they are at &0000 and &0400. So maybe worth changing that for future safety !!

If in future the granularity gets smaller, it’d cause problems for code that assumes it’s mapped in a region of memory with a single call, wouldn’t it?

Yes, but the 1MB granularity has only ever been publicly documented for OS_Memory 14/RISCOS_AccessPhysicalAddress. OS_Memory 13/RISCOS_MapInIO make no mention of the granularity used; it’s only be looking at the source code that you’ll see that it’s 1MB. So if any code works under the assumption that the latter two calls map in 1MB regions then it’s not our fault if it suddenly fails one day when it tries accessing memory outside the area it requested ;)

Quite! Would it be overly pedantic to update the documentation to say ‘MiB’ rather than ‘MB’? Is the intended meaning just so blindingly obvious to anyone with a clue that there’s no point!?

Feel free to update the docs – pedantry is always good in documentation. But in this case I think the meaning is quite obvious to the target audience.

Jeffry, on the subject of smaller granularity, your changes to add the NIC into the HAL only calls for 256 bytes in the Board_InitDevices_DevKit routine. The chip only has two registers to access, but they are at &0000 and &0400. So maybe worth changing that for future safety !!

Well spotted! I guess I should have looked closer at the data sheet :)

Yes, but the 1MB granularity has only ever been publicly documented for OS_Memory 14/RISCOS_AccessPhysicalAddress.

You’re quite right, of course. OS_Memory 13 takes a size parameter. This is the current OS_Memory 14 description:

The purpose of this call is to temporarily map in One Megabyte of IO memory at run-time. If multiple 1 Megabyte chunks are required keep calling this until done, when ready to release it is only necessary to release the first reference key – the kernel will then free the rest for you.

Is it a deliberate omission that you can’t specify a size when asking to map in memory temporarily? The above description is bidding people to assume that a temporary mapping request will always be treated in 1MiB chunks, and tying ‘our’ hands or risking breaking things if smaller granularity were available in the future…

Update: I still have my tx issue but i will release the driver to everyone who emailed me tonight after i take one more shot at sorting the problem.

Thanks and good luck with your marriage!

Is it a deliberate omission that you can’t specify a size when asking to map in memory temporarily? The above description is bidding people to assume that a temporary mapping request will always be treated in 1MiB chunks, and tying ‘our’ hands or risking breaking things if smaller granularity were available in the future…

It’s a deliberate omission. Looking at the source code, I can see that the docs for OS_Memory 14 are actually rather poor:

• The docs make no mention of the area being 1MB aligned (i.e. it rounds your address down to the nearest MB, maps in that MB, then returns the address of that MB + an offset to point to the actual physical address you requested)
• The waffle about mapping in/releasing multiple 1MB areas is misleading. In reality the logical memory map has a single 1MB area which is shared by all users of OS_Memory 14 – i.e. only one 1MB block can be mapped in a time. OS_Memory 14 returns the old state of the mapping in R3; calling OS_Memory 15 with that value of R3 restores the mapping to that state. So if you call OS_Memory 14 multiple times, then call OS_Memory 15 with the first value of R3 you got, then it will do what the docs say and restore the mapping to the state it was before your original request (but the “kernel will free the rest for you” bit is nonsense since there was never any more than one area mapped in anyway)
• Because the 1MB area is shared, it means that the mapping is very temporary. I.e. you can’t just map it in during your module initialisation and assume that it will stay there until shutdown (another module could try using the same tactic, and all hell would break loose)
• I’m fairly certain I saw a comment somewhere about how horrible OS_Memory 14/RISCOS_AccessPhysicalAddress is, and how OS_Memory 13/RISCOS_MapInIO should be used instead if you’re interested in more than very temporary mappings (e.g. *Memory P uses OS_Memory 14). But I can’t find that comment now :(
• And of course the blame for the misleading docs should be directed at Castle’s StrongHelp manuals, not Alan’s wikification :)

Thanks for the detail as ever, Jeffrey. I don’t know where I got it from, but I did know OS_Memory 14 mapped in an aligned MiB. Can’t remember where I read it!

I had no idea the MiB was shared! That’s nasty! It sounds like turning off interrupts while using a temporary mapping would be a good idea.

And of course the blame for the misleading docs should be directed at Castle’s StrongHelp manuals, not Alan’s wikification :)

I’ll direct my daggers at them then ;) I’d never blame Alan – he’s done so much great work. He’s wikid.

It sounds like turning off interrupts while using a temporary mapping would be a good idea.

It should be OK as long as programs are well-behaved and use OS_Memory 15 to restore the region to its previous state after each access.

For stuff that sits in the grey area between permanent mappings and temporary mappings (e.g. if someone was to invent a hot-pluggable memory-mapped expansion bus), I think the only way to handle it at the moment is to create your own dynamic area and explicitly request which pages you want. This also has the advantage of allowing you to use a lower granularity (although I have a feeling you’d be forced to do that anyway – I don’t think DA’s support 1MB mappings)

I’ve updated the wiki now, so things should hopefully be a bit clearer :)

I’ve updated the wiki now, so things should hopefully be a bit clearer :)

What wiki are you referring to?

What wiki are you referring to?

The ROOL one (Are there any other wikis with that OS_Memory documentation on them?)

What wiki are you referring to?

The ROOL one (Are there any other wikis with that OS_Memory documentation on them?)

Dunno, mate :-) There are lots of wikis (and some of them are big enough to each look like a collection of wikis) in the RISC OS world. I’m not familiar with all of them.

The wiki for OS_Memory 14 makes it look as if it is intended for calling from within a module. Can I use it from user space too?

I’m interested in the possibility of hardware expansion of the BeagleBoard. I’ve found the relevant section of the OMAP TRM and I understand it. I’ve found what appear to be some suitable level shifter ICs too, so I can go between 1.8 V and 3.3 V or 5 V, bidirectionally or unidirectionally. I can work out how to connect up a character LCD module, for example.

The wiki for OS_Memory 14 makes it look as if it is intended for calling from within a module. Can I use it from user space too?

I have a feeling that the page will be mapped in with the protection flags set to deny access from user mode. So as long as you remember to switch into a privileged mode (and are careful to restore the old state before calling Wimp_Poll, or exiting your program, etc.) you should be fine.

IGEPv2 NIC ethernet driver has been released to the beta testers.

After we do a few iterations of bug fixes i’ll release a general version for everyone who wants it.

Before releasing i checked that the driver could withstand a flood ping attack while transfering a 300mb file. Didnt see any issues.

The wiki for OS_Memory 14 makes it look as if it is intended for calling from within a module. Can I use it from user space too?

Dave, Jeffrey’s right: You can map in memory from user space, but you can’t access the memory unless you’re in a privileged mode. Tyring to do so for example from BASIC gives an “Abort on data transfer” error.

It should be OK as long as programs are well-behaved and use OS_Memory 15 to restore the region to its previous state after each access.

I’ve re-read what you posted now and it makes sense. Calls to OS_Memory 14 operate a bit like a stack, so as long as they’re nested properly (with OS_Memory 15, I mean), the mapping will always be as expected. Not a good bit of the architecture for pre-emptiveness, eh? ;)

Guess my next job is the wireless eh?

I’m guessing i will need to setup everything on the wireless card myself and provide a *command replacement for iwconfig? WPA may be an issue but i suppose we could start with WEP. Guess it depends on how much work is done in the firmware.

Has anyone managed to get the bluetooth going on the IGEPv2?

Guess my next job is the wireless eh?

That would be great. I can’t really offer any constructive advice about how you’d go about that other than suggesting that examining ISEE’s Linux code is about the only way to go I should think. Something like the Linux dump you did before for the SMSC chip would probably be very instructive. I don’t know anything about the security protocols. Why is WPA such an issue? Does it require a big library of support code?

Has anyone managed to get the bluetooth going on the IGEPv2?

I’ve never tried. I think people have reported working bluetooth peripherals on the ISEE forums. There were rumours about the a9 having at least some bluetooth support, but I never saw or heard of anything actually in action.

Did I mention that I have a USB stick (actually a USB microSD card reader) that makes my IGEPv2 card run amazingly slowly if it’s plugged into my hub at boot time? It’s quite an interesting phenomenon. I can see modules initialising about 1 per 5 seconds as opposed to the normal (pretty fast) speed. It doesn’t have to have a microSD card in it for the problem to appear, either. And if I wait until RISC OS has booted and then plug it in, everything’s okay!

Is there anything useful I can do to debug this, Jeffrey? If not, I could send you the device if you were interested.

I sometimes see things start running in slow motion too. Its painful.

IMHO the usb layer needs a rewrite/re-port from the latest BSD source.

WPB how did you get on with that NIC driver?