SD Card Filer

Congratulations, Ben, on releasing the SD card filer etc. I am sure it was a large amount of work – and more than you anticipated!

However, can I relate my initial experiences, having just downloaded the OMAP3 development ROM and tried it on my BB-xM revC…

1. I have Reporter set to start at boot (I would!) but it seems to abort at FC0442A8. This stops the boot in its tracks. Worse, any command then issued also aborts at &FAFF33C8. While I try and investigate this, the remedy for anyone afflicted is to rename (on a working machine!) Run to Run+Rep, and Run-Rep to Run to stop Reporter starting at boot. Currently I have no idea what is causing this – ROM changes, Reporter, or a combination. It did work ok with RO5.19 from 31 May. Note that REporter seems to start up without problem manually.

2. There is a severe performance problem somewhere. If Filer widows are small or large icons, all seems well. If full info is selected, then the Filer module seems to takes aaaaaages in Redraw Window. It seems that for every file in the Filer window, two SaveCMOS SDFS::RISC OS.$.CMOS commands are issued. Perhaps these are taking the time. It is so slow it is almost impossible to use! Beware!! I do have a CMOS widget installed, and my SD card also has a CMOS file (coz SDcreate put it there).

Both these problems may be caused by me, but thought it best to let others know.

And yes, I do realise it is only Beta, Development, etc etc.

Hi Martin. Thanks for the report – this is exactly what beta releases are good for! Any chance you could load DebugTools or similar and do a *Where on those addresses?

Further observations…

Some other commands (eg some Reporter commands) also provoke the two SaveCMOS commands (which I now see cause the two leds just above the sd card to flash!).

RMkill SDcmos fixes? performance problem.

I have managed to provoke (by innocently using commands) both the above aborts.

FC0442A8 is in Utils module +D360. It is the STMDB r13! just before which I think is the problem … r13 is FA200004.

FAFF33C8 is not in any module, but just before is another STMDB r13! and r13 is &FA200000. This then needs a re-boot to recover.

Both remarkably similar!

Hi. On the performance front (and the SDCMOS thing), we’re seeing similar issues. I think this is highlighting a lot of unnecessary CMOS writing by various bits of the OS (e.g. the Filer for one thing). I suspect some hitting with a hammer will be required… That’s not to say there are no bugs in the SDCMOS module, of course!

Had initial difficulty in running this version until I saw the ‘delete cmos file’ note. Also couldn’t complete !Boot until I noticed that mbufmanager was unplugged.

Looks as if the resolver module still needs to be moved though.

[Edit] Erk! or Unplug SDCMOS, even.

Another oddity – my CMOS file timestamp seems to be 2 hours ahead of machine time! And yes, *Time is giving correct time.

A Filer window on my SD card, when set to full info, takes about 20 seconds to write the 6 items on the card, and I think is doing 2xSaveCMOS for each line. When completed, it starts again from the top … etc.

Another oddity – my CMOS file timestamp seems to be 2 hours ahead of machine time! And yes, *Time is giving correct time

Seeing that here too.

I’m just getting continuous writes (I presume) to the CMOS file which makes the whole machine run in treacle.

(Am I right in thinking there’s one LED for write & the other for read? In which case amend the above to ‘read & write’.)

Thick treacle here!

I have been trying to discover what the difference is between Reporter commands which cause 2 CMOS writes, and those that do not. As yet I can not see what the difference is! One thing I am certain of is that Reporter does NOT write the CMOS – indeed it does not even read it! None of the commands I have tried have any Filer-related activity either. So why the CMOS writes for some Reporter commands?

Presumably the OS_Byte intercept in SDcmos has been triple-checked to ensure it is not intercepting more than it should? Unfortunately OS_Byte is heavily used anyway, so it is hard to see any effects externally.

Re file dates: I have now dared to save a new small text file to my SD card: The initial time it is given is one hour ahead. If it is saved again (ie it already exists) it is given a time two hours ahead. Most odd!

I have now dared to save a new small text file to my SD card:

Did that by accident. I can confirm that an obey file to unplug SDCMOS will run from SD. Oops!

Thanks for the comments!

Clearly there are some gremlins with SDCMOS. To be honest, I threw it together in a couple of hours in the hotel room the night before the Wakefield Show, and beyond some simple testing that it did the right thing in the various circumstances it might encounter, I haven’t generally had it loaded while doing all the other development testing. If you look at the sources, you’ll see the ByteV intercept routine really is very simple. There do seem to be rather an improbable number of writes to CMOS though, which is that much more noticeable with a slow mechanism which also flashes an LED at you, so I suspect something somewhere has been misbehaving for some time.

If you’re concerned about the speed, a quick fix is, as people have mentioned, to *RMKill SDCMOS, or even *Unplug it. If you’ve got the EEPROM widget, you really don’t need the SD copy of CMOS anyway.

On the date thing, I’m guessing it’s a previously un-noticed DOSFS bug. I just tried *SaveCMOS to both a FileCore-formatted and FAT-formatted card. The FileCore one had the correct date, and the FAT one said “02 Jan 2098”. It probably doesn’t help that my clock is at 1970, but there’s no way that should be translated to a date in the far future!

The LEDs are different on different boards. IGEPv2 has a bi-colour LED, so that should flash green for reads and red for writes. The original beagleboard has two LEDs very close together next to the SD slot, so to make it more visually obvious what was a read and what was a write, I’m flashing both together for writes and just the one for reads. On the beagleboard-xM, the two LEDs that are connected the same way to the OMAP are further apart (opposite sides of the microSD slot) so for simplicity I’ve left them working the same way as the original beagleboard (both = write, one = read).

Aha, it’s Territory Manager’s fault. It writes to the DST bit in CMOS rather a lot. J’accuse Sprow :)

Another reason why I probably didn’t notice this before is that that change to Territory Manager went live less than two weeks ago, so wasn’t present in the build tree I’ve been developing with…

Well, a fix for the Territory Manager thing is in CVS, so will make tonight’s autobuild. The abort is a bit more of a mystery – the address is in “Read” in Kernel.s.PMF.i2cutils, and suggests the SVC stack pointer is wrong (misaligned or completely corrupt) when the kernel reads CMOS, which shouldn’t be affected by the ByteV intercept. If you can characterise if more or provide a register dump, that might be useful.

Those crashes look like they’re the result of stack overflows – presumably due to something in the filesystem stack triggering a CMOS write while SDCMOS is in the middle of saving.

A few suggestions:

• Use a callback to trigger writing CMOS instead of doing it from within ByteV
• Add a delay to the callback (maybe just a centisecond or two?) to avoid writing the file hundreds of times if some CMOS bytes are changed in quick succession.
• Add some way of working out which writes actually changed CMOS, so you can avoid writing the file when redundant writes are made (like Territory Manager was doing). I guess you’d either need to keep your own cache of CMOS, or find some way of hooking into the kernel’s cache, or just issue a read before every write.

The abort is a bit more of a mystery …. If you can characterise if more or provide a register dump, that might be useful.

I will have another go with tomorrows ROM.

One of the nice things about it being inside ByteV is that the errors get passed back to the caller though – so if the user clicks “Cancel” on the media search dialogue then whatever issued the OS_Byte receives an appropriate “Disc not found” error.

The PRM says the re-entrancy of OS_Bytes 161 and 162 is “not defined”, which is a bit of a cop-out. For many years, the CMOS was only found on an I2C bus and the I2C module wasn’t re-entrant, so they should really have been documented as not reentrant since anything which wrote CMOS from the background would have been unreliable at best. I doubt any of the filing systems would have got away with writing CMOS from the background as a consequence. Looking at the sources, I don’t see anything in FileSwitch, FileCore or SDFS which would be writing CMOS asynchronously, or synchronously inside *SaveCMOS for that matter, so I suspect something else must be going on.

Yes, we could keep a cache. Actually, it’s probably easier to read from the kernel’s cache using an OS_Byte 161 call. Though CMOS writes are still quite slow on other platforms like Iyonix and IOMD as well as on all older OS versions, and none of those filter out ineffectual CMOS writes. CMOS writes are (Territory Manager excepted) such rare occurrences that I don’t know if it’s worth the effort, because for consistency, you’d want to add the check to every implementation of non-volatile RAM.

Probably naive question – Is it now possible to update ROM images by writing directly to the SD with SDFS?

I have any problems with the new ROM. The desktop and filer are very slow. But it was possible to write a older ROM back to the SD with SDFS.

Handy.

Very simple. A new icon in the iconbar. Like any other drive.

Certainly posible to change ROM Images using SDFS – using RISC OS I copied the ROM from 31 May to the SD card with another name, then renamed todays, and renamed 31/5 to riscos. Then reset, and it worked and loaded the 31/5 rom. Trouble was, I then could not rename it back without SDFS! I had to take it to a Windows PC and put todays SD image back. Talk about chopping off the branch I was sitting on…

What I understand from your post (no dictionary at hand) can not work. When you reload an old ROM again do of course also the SD support is gone. Excuse me if I should have misunderstood something.

That’s what Martin said, Raik. He could change to an older ROM but not back.

Should make future installations easier. Think I’m shortly going to gain a surplus of SD cards.

The same I wanted to say;-) From now on (starting point) can be modified via SDFS. Previously only helps BBFlash or another detour…

Trouble was, I then could not rename it back without SDFS! I had to take it to a Windows PC and put todays SD image back.

What did you expect to happen? ;)