SD Card Filer

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.

Is this for development or is it planned to stay? There aren’t many LEDs going, and I can think of several potential uses:

• Filesystem access (as you’re doing now)
• System-okay blink, with a faster blink if an errorbox has happened.
• You-have-mail.

I’ll have a poke around the assist-chip (65950) datasheet to see if I can work out how to use the PWMable LED for BeagLEDs Second Ed. (it’ll look way cooler, at any rate). Must check to see if the original Beagle uses compatible hardware!

Is there a hook/vector into your LED code to allow other filesystems to make use of the LEDs? If/when mine works, I’ll be likely doing most stuff with a mounted USB stick. Blinking for that would be nice. ;-)

I’ll have a poke around the assist-chip (65950) datasheet to see if I can work out how to use the PWMable LED for BeagLEDs Second Ed.

IGEPv2LEDs does this, too, writing to the appropriate 65950 registers. And you’re right – it does look cool! ;)

Just a quick note to say I dug out my DevKit board and updated the ROM to the latest, and the SD card is on the Icon Bar and I can read files. Not tried writing yet!

Today’s ROM is much better – thanks Ben. The treacle-look has gone, no myriad of SaveCMOS commands, Filer Full Info works at full speed, and the strange aborts have gone! Reporter now starts happily at !Boot again.

However, a new file saved to SD card still has timestamp +1 hour, or +2 if file already exists. I also noticed that the CMOS file is now dated 2/1/2098, presumably because it was written at some time before NetTime had done its stuff.

Oh – and I updated to today’s ROM by using SDFS to copy/rename the riscos file and re-booting! No PC involved!! That in itself is a major step forwards.

some time before NetTime had done its stuff

Could you check you’re using NetTime 0.39 or later? Earlier versions had some set top box Euro/Australia rules in them and attempted to double correct for daylight savings. That’d give you +2 overall.

file is now dated 2/1/2098, presumably because it was written at some time before NetTime had done its stuff

I think I’d have expected 2054 (2012 + (2012 – 1970)) though.

My NetTime was still v0.36 – softloaded as it is not in ROM. I am now using v0.40, and the results are even stranger!

At *time Sat,09 Jun 2012.11:32:40 …

New file saved as 13:14:08 09 Jun 2012
Existing file saved as 14:14:08 09 Jun 2012

… even when repeated several minutes later!

That seems even worse!!

Oh – and I updated to today’s ROM by using SDFS to copy/rename the riscos file and re-booting! No PC involved!!

Threw caution to the wind & just dragged the new ROM from the archive to the SD. No apparent problem… we have ignition.

I’ll play with SDCMOS.

This is not true: see later posts

Update: using NetTime v0.40, the results are also dependant on FileType!!

At *time Sat,09 Jun 2012.11:43:32 …

New Text file saved as 13:14:08 09 Jun 2012
Existing Text file saved as 14:14:08 09 Jun 2012

New Data file saved as 12:41:42 09 Jun 2012
Existing Data file saved as 13:41:42 09 Jun 2012

… even when repeated several minutes later!

The saves were from Edit.

New Directories are given a timestamp of +1 hour.

CMOS file +2hrs, text saved from Zap +2hrs.

Update: using NetTime v0.40, the results are also dependant on FileType!!

What does a control experiment writing to (for example) a RAM disc or USB memory stick do? There’s not much to conclude remotely when 2 things are changed at once.

Text to RAM disc gives correct time. Same to USB stick gives correct time. Same for data file, correct. New dir, correct for both.

Using NetTime v0.40, the results are dependant on how you save from Edit.

If you ensure the file has been changed before every save (ie * in titlebar), then…

For both Text AND Data files to SD card…
New file saved as current time+1 hour
Existing file saved as current time+2 hours

RAMdisc and SCSI (USB stick) are current time (ok)

If the file in Edit has NOT been changed (but has been previously saved somewhere), then…

For both Text AND Data files to SD card…
New file saved as original save time+1 hour
Existing file saved as original save time+2 hours

RAMdisc and SCSI (USB stick) are original save time (ok)

I hope that helps – confuses me! Any more questions…?

On the LEDs, I didn’t see it as within the remit of the SD work to create a generic LED interface, and I think my time’s better spent at the moment on making the main hardware work on the other platforms. I can conceive of a module which provides a set of “logical LEDs” which are multiplexed onto “physical LEDs” in some manner which has to take into account both board differences and user preference, but that’s orders of magnitude more effort than the approach I’m currently taking.

The way SDIODriver uses the LEDs is at quite a low level. That means you’ll see them flicker during bus auto-negotiation when you insert a card. This also means that if you were to insert, for example, an SDIO wifi card, the LEDs would operate as network activity lights as well.

It’s also worth noting that due to the way the OMAP GPIO registers are designed, it’s possible for different modules to flip the state of those two LEDs without interfering with each other’s operation – there’s no need to keep soft copies of the registers like you do on other architectures like IOMD, so no need for a single owner of that soft copy. SDIODriver doesn’t stop you from, for example, using one of the LEDs as a heartbeat, it’s just that there’s not currently any way from stopping it from being used as an activity indicator at the same time.

Just a quick note to say I dug out my DevKit board and updated the ROM to the latest, and the SD card is on the Icon Bar and I can read files. Not tried writing yet!

Excellent, thanks! If you can try writing, please check that I haven’t got the sense of the write-protect tab the wrong way around – that’s something I couldn’t really be sure of from the schematics because it depends upon the mechanical design of the SD connector. Are the LEDs working like the beagleboard ones?

CMOS file +2hrs

I’ve had a bit more of a play with these today. FileCore-formatted SD cards don’t have this bug. Files created using the simplest APIs are advanced by 1 hour, and as people have noted, those created by *SaveCMOS are ahead by 2 hours – I think this is because *SetType increments the time by 1 hour, and *SaveCMOS creates a file then sets its type as a separate operation.

Checking on SCSIFS, I’m seeing exactly the same thing – times are 1 hour ahead on FAT media are one or two hours ahead, but not for FileCore media, so it’s not a new bug. The beauty of code reuse, nobody has spotted this for FAT-formatted USB sticks up till now! IIRC, FAT stores timestamps in local time rather than UTC, so my guess is that DOSFS is only adjusting for DST in one direction, so a read-modify-write of the file attributes ends up skewing the timestamp by an hour…

If you can try writing, please check that I haven’t got the sense of the write-protect tab the wrong way around – that’s something I couldn’t really be sure of from the schematics because it depends upon the mechanical design of the SD connector. Are the LEDs working like the beagleboard ones?

Ben, writing works fine, and two LED’s flash when writing, and one when reading so all looks good.

Great, do you get the “disc is write protected” error if you slide the “lock” tab down and try again? It’s at the top left of the card as viewed from the label side (except for MMC cards, they don’t have one).

do you get the “disc is write protected” error if you slide the “lock” tab down and try again?

Yes.
I just formatted a 4GB class 6 card as well !

1. Do we need (have?) a FAT formatter?

2. I take it that it’s now advisable to do a dismount when hot swapping SD cards?

Tank: thanks, that sounds like all the DevKit8000 differences are working fine, unless you have any MMCplus or MMCmobile cards so you can check that 8-bit cards work (and even if they don’t, the code should drop back to 4-bit mode).

Frederick: at the present time, HForm only lets you format cards to FileCore format. The same is true of USB card readers, memory sticks and hard drives. If you want to switch back to a FAT format, I think you need to use another OS to do so.

As for dismounting, behaviour is the same as for SCSIFS and ADFS. I think the rules are that you should dismount if it’s FAT formatted, but there’s no need to if it’s FileCore formatted.

Thanks Ben. I was just thinking in terms of the BB -xM’s boot micro SD given that it now can be written to (hence dismount rather than just swap) and is FAT.

Ben: re SCSIFS and FAT media: On 5.18 Iyonix timestamps are ok, but on BB with today’s 5.19 there is the +1 +2 effect… but much has changed, unfortunately. Presumably if you suspect DOSFS, it is being used in the background and is not obvious to my untrained eye?

What is best way to tell what format a disc is? HForm and FAT USB sticks look the same to me (on the computer I mean!).

It’s obvious if running Fat32fs

To which I should probably add that I am and seeing the same as Martin.

My development SD card was named ‘RISC OS’. I tried a “*SaveCMOS SDFS::RISC OS.$.CMOS” which failed with syntax error. I then tried again with a Alt-space in RISC OS instead of just space, and the saveCMOS seemed to work. I then tried to rename the SD card to RISCOS to avoid this and got an abort from the filer (sorry, did not note where!). Could not open the SD directory. Tried restart … did not even seem to try and read the SD card at all!

Reverted to my v5.18 SD card, and BB started ok. Phew!

So, I assume SD card is screwed. Before I try re-formatting it and writing the v5.19 image back on my PC, I will try to read it in case it is useful for diagnostics.
[edit] I now have a dump of the card – all 1.86GB of it in case it is of any use. I thought it would zip well, as most is probaly x00 … but no, it only reduces it to 1.80GB! SD card has restored ok, it seems. Back to the BB now..

In the meantime, do not try what I did at home, folks!

What is best way to tell what format a disc is?

From BASIC, something like

DIM block 64

SYS"ADFS_DescribeDisc",“:0”,block

PRINT ~block!32

substituting your filing system name and drive as appropriate for the thing you want to ask. A value of FC8 is a DOS disc, FCD and FCE are FileCore. Not sure that qualifies as “best” but it gives the answer.

With ADFSFiler, there’s the “Current format” menu item to do this, of course, but sadly that’s never been implemented for the other filing systems.

There are other things you can do to detect DOS discs indirectly – for example if you create a file with load/execution addresses (*Save :0.myfile 8000 +0") it can’t because you can’t store that information on a DOS disc. (You may also notice this when doing file copies via FilerAction because incomplete files temporarily have load and execution address &DEADDEAD.) Or try changing the capitalisation of a filename, which falls foul of the arcane rules in which they’re mapped onto 8.3 DOS filenames behind the scenes. A slightly easier way is to look at the disc maps in the Task Manager – if the disc is FAT-formatted, no RAM will be allocated to the dynamic area for that drive.

It is possible to put !Boot and the like on a DOS-formatted disc, even the same one containing the bootloaders. I’ve tried it with a beagleboard, and it works, for the most part – but there are clearly many bugs in DOSFS, as well as in applications which assume it behaves the same as FileCore. It doesn’t help that FAT is a very poorly designed format to begin with – it’s tragic that it has gained such a foothold in consumer electronics in general.

After a few more experiments, I can report that timestamps written by our lastest DOSFS read back OK on Windows but not on Linux. Timestamps written by Linux read back OK on our latest DOSFS, but not ones written by Windows! I’ve been doing some googling on the issue of its handling of timestamps, and it’s a complete mess, even handling of leap seconds seems to need to be taken into account. Does anyone here already understand how it’s supposed to work, by any chance?

If you actually care about the data on an SD card, it’s much safer if you format it with a FileCore format, I think.