Towards BeagleBoard "CMOS RAM"

You wouldn’t believe it, but…

After a pause (during which I did, at least, release a VoIP soft phone for the Iyonix!), I’ve got back to working on the SD/MMC driver again. Only to discover that the C source directory was broken again.

This time I seem to have recovered the single file that was there. Again, it looks like it was trampled on by something from Netsurf, though that doesn’t by any means indicate that it’s Netsurf’s fault.

I’ve just changed the boot image to Jeffrey’s of September 3rd.

When I get a chance, I’ll try setting up an automated test to try and track down these file corruption issues. I’ve got a new 16GB USB stick and a 500GB hard drive that are just waiting to be broken.

I’ve just changed the boot image to Jeffrey’s of September 3rd.

When I look again this morning at what I wrote last night, I realise that what I wrote is wide open to misinterpretation. I have changed the boot image since the corruption happened.

My suggestion is that the ROM image should have a reserved area of 1k where the ‘factory’ CMOS RAM settings are stored (I know the ‘factory’ setting is probably all zeroes) [perhaps plus a check-sum].

fatload mmc 0:1 0x81000000 riscos
[fatload mmc 0:1 0x813FFC00 cmos]
go 0x81000000

This addresses the main issue of having something like a beagleboard start up how you want it.

If a ‘CMOS save’ allows a save to ADFS storage then this can be the way to get a different ‘cmos’ file onto the SD card using the beagleboard itself.

In other words it removes the requirement to write an SD card driver from the ability to have a ‘functional’ CMOS start up configuration.

I’d rather see a proper solution than a hacky one. Feel free to implement that solution yourself, but don’t expect me to spend time implementing something that’s going to be redundant once we have a proper solution in place :)

I’m with Chris on this one – at least as a stop-gap measure until a proper SD/MMC driver is working. On that score, my progress recently has been roughly zero. I haven’t heard from Uwe either – there’s no good reason why I should, he was expecting me to to make more progress that I have; I’m not blaming Uwe at all, just stating where we are.

It seems to me that the stop-gap could be got going quite quickly and would give useful benefits, whereas the SD/MMC driver may well take some time.

OK, fair enough. Since we were likely to need to add support for some kind of boot argument string I guess it wouldn’t be too much hassle to implement support for that now. That way we won’t have to worry about loading the CMOS file to a magic address in memory (or to a magic offset inside the ROM image); instead you just specify the address as a boot argument. This may also give me the impetus I need to release/finish the RISC OS port of the mkimage tool (since the easiest way of getting u-boot to pass the ROM some boot arguments is to package the ROM as a uImage)

Dave – does your lack of progress mean you’ll be giving up on the SD/MMC driver? I could probably turn the experience of writing it into a how-to guide that covers things like writing a FileCore-based filesystem, dealing with interrupt handlers and I/O, integration with DMAManager, etc.

Dave – does your lack of progress mean you’ll be giving up on the SD/MMC driver?

I wasn’t sure whether I was going to get involved in support for iyoPhone, but as only one person appears to have used it, that now seems unlikely. (There is a problem with the AudioIn module – and there always was – but I rate my chances of finding and fixing that as slim to zero.)

So I’ll have another go at SD/MMC. However, I really hardly scratched the surface, and then it didn’t work, so there really is nothing of any significance to go on so far.

I haven’t looked into it in any great detail yet, but could cmosd on this page be of any use here? As a stop-gap.

I’ve restarted work on SD/MMC, but I’m still having no sucess. I’m still mired in the card identification stuff; nothing seems to work (I know that’s a sweeping statement, but you wouldn’t have the attention span necessary to read all the things I’ve tried!) The best I’ve had is going as far as sending CMD0, CMD8, CMD55 and ACMD41, but the responses from CMD8 onwards are one command late, which shows that something is getting out of sync. I didn’t think that was even possible.

I haven’t heard from Uwe in a long time, either, and he hasn’t replied to my e-mails of the last couple of days.

I’ve tried searching for application notes and any source code that might help, but without success.

Sorry it looks bleak, but that’s reality right now. Structured trial and error; unfortunately just as much error as trial.

Suddenly, with one change, it’s all looking much better. I’ve applied a software reset to the mmci_cmd line after setting the clock up the first time. Now I’m getting the correct response to CMD8, at the right point in the code. Now to see if the responses to CMD55 and ACMD41 are correct, or at least plausible.

... and finally, before I go to bed tonight: I seem to have got through the card identification process successfully, although the status bits from the last command are different from what I would have expected. The code works on an SD and an SDHC card.

So some real progress at last.

And it hasn’t eaten my hard drive either :-)

...I seem to have got through the card identification process successfully…

That’s great news – thanks :-)

More progress: I have successfully read a couple of blocks from my SD card tonight. I can recognise the MBR and partition table; I have also read the block that the partition table entry points to, and that looks entirely plausible too.

My code is a dog’s breakfast – it bears all the hallmarks of being highly experimental – so I need to work on cleaning it up.

OK, guys, what do we need as the API to this? I’m only interested in providing substitute CMOS RAM at present, not a general purpose filing system. I’m thinking of a call to initialise, a call to read 1024 bytes, and a call to write 1024 bytes. Maybe a call to finalise too. Fix the file’s name as “cmos/dat” within my code.

More progress: I have successfully read a couple of blocks from my SD card tonight. I can recognise the MBR and partition table; I have also read the block that the partition table entry points to, and that looks entirely plausible too.

Excellent!

OK, guys, what do we need as the API to this? I’m only interested in providing substitute CMOS RAM at present, not a general purpose filing system. I’m thinking of a call to initialise, a call to read 1024 bytes, and a call to write 1024 bytes. Maybe a call to finalise too. Fix the file’s name as “cmos/dat” within my code.

I think the best API choice would be one that matches HAL_NVMemoryRead / HAL_NVMemoryWrite – i.e. it allows for an arbitrary number of bytes to be read/written, starting from an arbitrary address. This can easily be implemented by having a simple software cache ontop of the block-based lower-level interface. Whether the code ultimately ends up in the HAL or in a module, you’ll almost certainly need a byte-based interface in order to interface it with RISC OS.

Another little update.

I’ve tidied up and refactored the existing code a bit, and reached the stage where I have to begin FAT operations. I’ve read the key FAT parameters (FAT16 or FAT32) from the card. It all looks to work on SD and SDHC.

Uwe is back in contact; the earlier code I sent him seems to have produced all the right results on several cards. I’ve sent him two more versions to try, including the last working version of tonight.

I’m not sure how much difference there is between FAT versions, but the SD cards created by SDCreate will all be FAT12. So in theory all you need to worry about is writing enough code to find a file in the root directory of a FAT12 partition.

the SD cards created by SDCreate will all be FAT12

FAT12? Are you sure? I thought that was only used on floppies. I didn’t think it supported devices as big as typical SD cards.

I’ve always been booting off a FAT16-formatted SD card. I believe it’s possible to boot off SDHC too, and they will normally be formatted FAT32 in order to avoid huge cluster sizes.

FAT12 is a bit harder that FAT16 and FAT32 in that the FAT entries are one and a half bytes, packed, rather than the 2 or 4 for FAT16 and FAT32. I’ll have to check whether there is any difference in the BPB for FAT12 - I imagine there must be.

Yes, they’re definitely FAT12. Rather than making a partition which fills the whole card it just uses a fixed-size partition of 8MB, for which FAT12 seemed to be the only option. (Using a fixed-size partition was easiest, since it saved me from writing my own FAT formatter. Plus a fixed-size partition was the only real option if I wanted the ability to save the SD image as an image file instead of writing it straight out to the card)

Yes, they’re definitely FAT12.

OK, no problem. Adding a third FAT type doesn’t complicate it much. The strategy is the same for all three; one or two of the details vary slightly.

I’m definitely keeping FAT16 and FAT32 in too. I refuse to ruin a perfectly good SD card by falsely rewriting the partition size :-) I’m sticking to properly formatted SD and SDHC. I imagine some other people will too.

Jeffrey, here’s a sentence quoted from Microsoft’s Hardware White Paper, “Microsoft Extensible Firmware Initiative”, “FAT32 File System Specification”, “FAT: General Overview of On-Disk Format”, version 1.03, December 6, 2000:

If your media is larger than 4 MB, do not bother with FAT12.

You really should be using a FAT16-formatted image with a small cluster size. Using FAT12 is non-standard.

How did you create the FAT12 image?

More to the point: can you create a suitable FAT16 image?

Extract from Jeffrey’s SDCreate Help file:

SDCreate creates SD card images in the following manner:

• The file !SDCreate.blank is a blank, 8MB FAT12 disc image created under Linux using the following script:

  #!/bin/bash
  dd if=/dev/zero of=BlankImg bs=8225280 count=1
  sfdisk -C 1 -H 255 -S 63 -D BlankImg <<EOF
  ,,0x01,*
  EOF
  sudo losetup -v -o 32256 /dev/loop0 BlankImg
  sudo mkfs.vfat /dev/loop0 -n "RISC OS" -F 12
  sudo losetup -d /dev/loop0

• This file was then squashed using !Squash to cut down the size of the program.
• So one of the first things SDCreate does is to unsquash the image. If the image is being written straight out to the SD card then it will be unsquashed directly to the card using the SCSIFS_DiscOp SWIs. Otherwise, it will be unsquashed to a file. This file will then have its filetype set to ‘DOSDisc’, allowing the FAT image to be used as an image file with DOSFS.

Using FAT12 is non-standard.

For reference, Linux still supports it

Yes, you’re right, I should rephrase that so it’s nearer to what I meant…

Using FAT12 for that size of medium is non-standard. It goes against Microsoft’s recommendations, so support on any given host computer might or might not work. FAT16 for that size of medium, by contrast, is recommended and standard.

At a rough guess, changing just one character in Jeffrey’s script above might be enough to avoid any potential problem.

After a couple of hours of messing around (and then the server eating my reply) I’ve come to the following conclusion:

• With a couple of modifications, the script I’m using for the 8MB partition can be modified to create a FAT16 partition of the same size
• The partition is recognised as bootable by the OMAP boot ROM, so that’s a good start
• However attempting to write to the partition using DOSFS will result in corruption or an error message, which is bad. It may be to do with the non-default sectors-per-cluster value that has to be used to prevent mkfs.vfat from warning about there being too few clusters (I can’t remember the exact error message DOSFS gave, but it was to do with clusters). Both Linux and Windows cope with the partition fine, so it’s definitely a DOSFS thing.
• Also gparted isn’t very good. When faced with the corrupt partition it silently runs fsck, filling the root of the drive with a few hundred .rec files. Not only does it not tell you that it’s found something wrong, but neither does it for permission before writing to the drive.

For reference, gparted only supports FAT16 partitions as small as 16MB, and doesn’t support FAT12 at all (or at least not in my version). So I can’t use that to create a small FAT16 partition.

If you can find a way of creating a suitably sized FAT16 partition that works with both DOSFS and the OMAP boot ROM then I’ll be happy to change to it. But for the moment I think I’m going to stick with what I’ve got (it took enough messing around to come up with a working 8MB partition in the first place!)