When should we have a new BeagleBoard ROM image?

Normally I have a hint of what you are talking about, however this one is totally over my head. :)

I wouldn’t advise trying to read the relevant chapters of the ARM ARM then :) It’s full of fun sentences like “A TLB invalidate operation is complete when all memory accesses using the TLB entries that have been invalidated have been observed by all observers to the extent that those accesses are required to be observed, as determined by the shareability and cacheability of the memory locations accessed by the accesses.”

Which processors does this apply to?

The ARMv7 ARM doesn’t make it entirely clear – I suspect it’s just ARMv6+, but I’ll check some older copies of the reference manual when I get home to see what they say.

What would the end results be? (Random lock ups?)

Memory corruption, a crash, or a lockup; it’s a bit hard to tell.

Does comprehending this stuff get any easier if you’re immersed in it for long enough?

Yes, although I’ve still got a fair way to go until I fully know and understand what to do in each situation. At some point I’ll have to sit down and try to read and comprehend all the relevant documentation, especially if we want to start writing kernel code that can be reused on multi-core chips.

Which processors does this apply to?

The ARMv7 ARM doesn’t make it entirely clear – I suspect it’s just ARMv6+, but I’ll check some older copies of the reference manual when I get home to see what they say.

So could this be responsible for random crashes in practice? I get a few that I just put them down to imperfect hardware. (Iyonix)

Possibly, yes. But I’d like to think that Castle/Pace knew what they were doing when they added XScale support to the kernel :)

There are probably a hundred and one rare crash bugs hidden in different parts of the OS and your programs. So I wouldn’t be too quick to point the finger of blame. The easiest way to find the cause of a rare crash is to debug it! (Although that isn’t always easy – occasionally my Iyonix locks up completely, seemingly with IRQs disabled, so if I wanted to debug that I’d have to run a custom ROM image with the serial terminal enabled. Not something the average user can be expected to do!)

Do you have any other USB sticks you can try?

I’m just running the one I created last night. No stiffing yet. I’m running a backup to NAS, which must have stopped at least half a dozen times yesterday and required me to pull and re-insert the USB drive. No problem tonight. It looks more reliable.

There’s a warning there for everybody.

Btw the new drive is an 8 GB own brand one from 7dayshop, which cost me about GBP11.49 all inclusive IIRC. Not bad. IDs are 090C:1000

Re: potential TLB maintenance issues on ARMv5. I’ve read through the relevant bits of the ARMv5 ARM, and the XScale developer’s manual, and unless I’ve missed something they don’t make any recommendation about whether TLB maintenance should be performed before or after the page table is modified.

Performing TLB maintenance post-modification is the only way to be 100% sure that the TLB is correct, but for the way that page table updates are performed in RISC OS I don’t think there’s any real danger of things going wrong. I’d have to take another look at the docs to make sure, but I think that only explicit memory accesses can result in entries being added to the cache/TLB. So as long as the OS makes sure nothing is using the target page, there shouldn’t be any problem with performing TLB maintenance before the update, because non-explicit memory accesses (e.g. branch prediction or instruction prefetch) would never result in the TLB being corrupted by reloading mappings that had just been flushed prior to the update.

I’ve got a couple of improvements to MUSBDriver that I’ll check in today/tomorrow. I’ve redone the OTG cable detection so that it’s fully reliable, and added support for the USBD_FORCE_SHORT_XFER flag as mentioned in the other thread. However none of these things strike me as anything that would fix any issues people have seen when plugging in specific devices.

At one point I was seeing a hang on boot if I had a hub + keyboard connected to the OTG port. This confused me a bit, since I’m sure I must have tested that config when I first got host mode working. But with the new version of the driver everything seems to be OK, and I’ve been able to boot with 8 or so devices connected at once without problems. So either the changes have fixed it, or it’s something else (enabling debugging, perhaps – stranger things have happened)

I’ve also started to look into the hub problems that occur with the EHCI port. Comparing the logs against what happens when I plug the hub into the OTG port, the first thing that stood out was that “something” was causing the EHCI controller to report a disconnection event shortly after the hub was connected. The hub was then being reset, which could conceivably cause problems if it didn’t like whatever reset timing is being used.

It looks like the NetBSD version of the EHCI driver has had quite a few important bug fixes and improvements made to it since it was last integrated with the RISC OS stack, so I think I’ll try applying all the bug fixes to the RISC OS version and see if that improves matters. I might also take a look at the hub code as well, just in case it’s something that’s been fixed there.

“something” was causing the EHCI controller to report a disconnection event shortly after the hub was connected.

Could it be something as basic as the difficulty (almost impossibility) of plugging anything in cleanly? Usually there is “bounce” amounting to at least a few milliseconds.

Quite possibly, yes.

I’ve just noticed that there is a new BB ROM image dated last Friday.

Ditto, also a Friday. But Jeffrey’s latest changes will have to wait for next time.

[Edit: I now see you’ve already spotted that Dave.]

After a couple of failed merge attempts I’ve succeeded in bringing over enough fixes from the latest NetBSD sources to get hubs working properly with the BB’s EHCI controller. Since I haven’t brought over any of their big changes it looks like it was just one of the simpler fixes that was needed (e.g. just four days ago there was a one-line fix made to their sources which could have expained why hubs weren’t working right).

Unfortunately since I’ve been trying to merge directly with the latest NetBSD sources I’m not entirely sure which fixes I have and haven’t applied (or even if all of them have been applied correctly). So now that I know that the NetBSD sources will fix the issue, I think I’ll go back to the original source and apply each of the simple patches in turn.

In case it’s of any interest, FreeBSD has a new USB stack. There’s a paper about it, which you can download from here

Interesting, but since the main aim of FreeBSD’s new stack seems to have been to provide better support for SMP I think it’s safe to say that it’ll be a few years until we (i.e. me) have to worry about porting it to RISC OS ;)

I’ve now done the bulk of the work to re-merge the EHCI driver. Luckily most of the patches applied without any trouble – there are only about 6 different sets of changes that are left to merge. I’ll try and get these merged and tested over the next couple of days, although I’m not 100% sure that it will be possible to get all of them working without taking the time to update the rest of the stack.

Out of interest, are any of the changes relating to performance or are they all bux fixes/other improvements?

Off the top of my head:

• Lots of bug fixes
• Some refactoring (either to fix bugs or to make things nicer). Some of this refactoring I’ll have to leave until we bring the rest of the stack up to date, because it’s quite invasive and involves changing many files. Luckily this refactoring isn’t too hard to leave out of the merge.
• Some performance-related improvements; they’ve messed around with how the EHCI driver handles interrupt endpoints quite a bit, but I think the interrupt scheduling code that we’re using was custom code written by Dan Ellis, so may not suffer from the performance problems that their code had. In fact, when I first tried to merge in their interrupt scheduling improvements it had the effect of making keyboards and mice near unresponsive! They’ve also split the task queue in two, which may have some performance benefits, but I think it was mainly to act as a bugfix for the behaviour of some drivers. And we don’t use the task queue on RISC OS anyway (no threads!) so that change won’t affect us.
• By far the biggest change to the EHCI driver is the addition of isochronous support. Apart from the code refactoring and the interrupt scheduling I think this is the only set of changes that I’ve got left to merge in. I think I’ve got a webcam which uses isochronous endpoints, but without a driver I don’t have any real way of checking that the code works – so it’s likely to go in completely untested.

Some of the structures that are shared between the USB modules have been changed, so I’m going to have to add some extra code to the modules to make sure that they refuse to operate if they’re being used with incompatible versions of each other. The existing versions of the modules don’t do any checks for version numbers, so these new checks will prevent people from softloading the wrong versions of the EHCI/OCHI/MUSB drivers ontop of their existing USBDriver, but won’t provide any protection against softloading a new USBDriver ontop of an older EHCI/OCHI/MUSB driver.

I’ve now managed to merge all the remaining EHCI changes in, and everything seems to work fine on my beagleboard. The Iyonix is proving a bit tougher, though – today’s set of changes cause the machine to lock up, and we’ve run out of space in the ROM image. Unless anyone’s got any better ideas, I think the easiest way of getting some extra ROM space is to squash the WIMP sprites, so I’ll have a go at doing that once I’ve worked out why my latest changes don’t work.

Unless anyone’s got any better ideas, I think the easiest way of getting some extra ROM space is to squash the WIMP sprites.

Other options could be the ROM apps (other than !Edit which is really useful to have if you break the boot sequence), or possibly the Econet stuff, though maybe there are still people using it. I’ve been doing this locally so I can include RTSupport and USB SCSI modules.

Squashing the Wimp sprites does look like it might be a bit tricky – the Wimp grabs a pointer to the data within the ROM rather than loading the sprite file into RAM. I’d need to look at the code a bit closer to work out exactly what it does with the ROM sprites – since 90% of the sprites will get replaced with higher resolution ones during boot it shouldn’t hurt if the ROM sprites were loaded into the main RAM sprite pool instead. If we can get this to work then it will save a nice 130k.

The tool sprites look easier to squash, especially since *ToolSprites replaces all of the sprites instead of just overlaying new ones ontop. Squashing those would save 23k.

At the moment I’m starting off by working on the Desktop sprites (i.e. the startup banner). These will compress from 48k to 7k, and they’re only needed the once at startup.

Other options could be the ROM apps

Did you mean remove the ROM apps or compress them?

I’d be wary of removing them, but it looks like there could be big savings from compressing them. E.g. Alarm is a 55k BASIC file that gets loaded by a second BASIC file, so it’s easy to modify that to be compressed. Chars could be compressed in a similar manner, although it’s only 3k anyway. Draw has 66k of sprites which could be compressed, and the !Draw module itself is a whopping 170k – if that was removed from ROM and instead held as a compressed module in Resources then it could save a lot. Edit is only a 10k module and has no sprites, so there’s not much to save there. Help looks like it’s an unsqueezed C program, so that could be squeezed (although it’s only 16k). And finallly Paint has 200k of sprites and a 92k module. Although if any of those resort to tricks similar to the Wimp then they may be trickier to compress than it seems.

Did you mean remove the ROM apps or compress them?

I was thinking remove them. Other then !Edit, they don’t need to be there given that everyone has a hard disc these days and they are downloadable from the ROOL website.

It looks like the apps are all designed to reference stuff from ROM where possible (the Alarm loader points PAGE at the BASIC file in ROM, the resspr_load function used by Paint (and probably the other C apps) get the pointer to the sprite file in ROM, etc). So if we were to compress the apps/resources then they’d start using as much RAM as if they were loaded from disc. So if space becomes an issue again it probably is just easiest to drop them from ROM.

If we’re going down the RO6 route, then can I just make one impassioned experience-laden plea: Please don’t remove Paint from the ROM. It and Edit should be given top priority. Everything else can go (especially Alarm, which is one of only three apps left in the ROL ROM, for reasons completely unfathomable to me).

...Desktop sprites (i.e. the startup banner). These will compress from 48k to 7k, and they’re only needed the once at startup...

...the !Draw module itself is a whopping 170k – if that was removed from ROM and instead held as a compressed module in Resources then it could save a lot...

Paint... and Edit should be given top priority. Everything else can go...

There are actually three Draw modules – Draw, which is used to draw individual paths, DrawFile, which is used to draw drawfiles, and !Draw, which is the ROM app drawfile editor. So we’d be getting rid of !Draw and keeping the other two.

That makes more sense to me now – thanks.