Towards BeagleBoard "CMOS RAM"

Recovering the space is easy, surely? Just create a second partition.

The trouble is that the process of formatting to FAT12 has overwritten the original partition size. Note that it is not in general possible to access the full binary size of a device. Attempts to do so often (depending on the design of the particular device) trigger a bug in the reader device that mean it has to be power cycled. YMMV.

It’s possible to format a device short, but how much of the original capacity you can recover is a guessing game.

I shouldn’t have said that it cannot ever be recovered. It can, but… as above.

Well, at tonight’s SAUG meeting, I demonstrated copying the files from a bootable SD card to an empty (formatted) SD card and booting from the latter. It’s another small step along the way.

Well done, Dave. Sounds like you’re making real progress. That’s great to hear. Keep up the good work.

Dave, why is it necessary to change the partition size? All the stuff required for mounting a FAT partition is in the VBR – including the sector count. My Fat32Fs does not compare the sector count in the VBR with the partition size. Do others?

I looked at the partition table entry in the Master Boot Record of a 2 GB Micro SD card, both as supplied and after formatting to FAT12 with !SDCreate. Before:

00 02 0A 00 06 3B FB BB 87 00 00 00 79 CF 3A 00

After:

80 01 01 00 01 FE 3F 00 3F 00 00 00 82 3E 00 00

The MBR consists entirely of zeros except for that partition table entry and the 55 AA at the end of the block. There isn’t any other record of the device’s size. Using !SDCreate has overwritten the only copy there was. (OK, there was a copy in the VBR too, but, as that’s within the FAT12 data space, it has been overwritten by one of the files.) As you can see from the above two lines, the device’s size has been reduced from 1973350912 bytes to 8193024.

In my case, I kept a copy of the first 1 MiB of the device, so I can write it back again and recover all the available size – and know it works.

In the case of other users of !SDCreate, they may never need to recover the full device size, so they won’t care. But if they ever do want to recover the device: the proper source of information may have gone. It certainly has in my case.

In the case of other users of !SDCreate, they may never need to recover the full device size, so they won’t care. But if they ever do want to recover the device: the proper source of information may have gone. It certainly has in my case.

Well I’ve had the 2GB card in and out of my BB, reformatted on the PC and various things and I’ve always been able to format it back to 2GB on the PC after SDCreate has written to it. I’ve also tried formatting it in my camera before, and although when first inserted, it reads it as an 8MB device, after formatting, it’s back to a 2GB capacity! They must be finding the full capacity from somewhere.

Hi Dave,

you can always do a READ CAPACITY at the SCSI level to get back the maximum partition size. Of course you cannot recover the original partition structure after overwriting it, that’s the nature of the game.

Dave,

(from memory, not at work where the datasheets are) for SD cards, you can use CMD4 or CMD5 to get information about the device. Max capacity was one of them. Maybe you can also read the maximum clock frequency so you can crank up the speed.

READ CAPACITY at the SCSI level

CMD4 or CMD5 to get information about the device

Of course. My apologies, I forgot about that. Presumably that’s what the reader/writers do.

I can also report that writing FAT12 appears to work now. Still lots more testing to do tough.

Great work Dave! Thanks.

I just wrote all 4 files to an empty 4 GB SDHC card and then booted from it. It’s going better than I thought :-)

You forgot the drumroll! Thanks for keeping all of us avid readers posted on developments :-)

Great Dave, that’s excellent news!

Has there already been discussion of what happens in the case of power failure when writing to the card? In the case of the CMOS settings file, it wouldn’t be critical if the file became corrupted – just annoying. But in the case of upgrading to a replacement ROM image, I guess the device could potentially become bricked.

If files will ultimately be written direct to the card from RISC OS (without the need to prepare an entire image and then write that out) then would it be useful if the previous ROM image were to be suitably renamed before writing the new one? Then would it be possible for the boot loader (sorry if that’s imprecise terminology) to read the superseded file in the event of a ‘RISCOS’ file being not present or corrupted?

would it be useful if the previous ROM image were to be suitably renamed before writing the new one?

IIRC Jeffrey’s normal image doesn’t have space for two copies of RISC OS.

IIRC Jeffrey’s normal image doesn’t have space for two copies of RISC OS.

Correct.

AFAIK it should be possible to create an unbrickable system by supplying the ROM images as uImages instead of raw ROM files. This should allow u-boot to verify the files before running them, and (assuming u-boot’s scripting language is powerful enough), allow it to automatically fall back to the backup image if the primary image is corrupt. There could still be the risk of other things going wrong (corrupting the FAT, boot sector, etc.), but that chances of that happening should be fairly insignificant (and there’s not much that a NAND-less system like the xM can do to recover from that without external help).

There’s scope for discussion about the degree to which the computer is bricked if power is lost at a critical point. I can see no reason why the BB should be damaged at all. The SD/SDHC/MMC card can, at worst, be reformatted in a PC running Linux, Windows or MacOS – again, no reason I know of why any permanent damage should be done to it.

No doubt somebody’s famous last words…

I am clearly doing something wrong but can not figure it out. Reading/Writing data to the SD card works without a problem but what I want to do is send a simple command for example CMD3 (read relative addr).The responds is always a ‘time out’.
I use :
MMCHS_ARG = 0

MMCHS_CMD = 0×031A0000

with the command : index=3, responds 48 bits, command with no data, enable index and CRC7 check.

I’ll have to look at this tonight, Peter. I’m at work now.

A general update: I’ve started on a flasher application for the BeagleBoard, which will be capable of writing all the files required for booting RISC OS. I realised how important it is when I wanted to reflash so often while porting the CMOS-writing code.

@Dave:
How did R-Comp deliver their OS upgrade to ARMini users? Somehow I read into their announcement that this was done via such a flasher and somehow I hoped that it was your effort they used.

Can anybody supply details on how the ARMini OS upgrade works?

It is my flasher core code, but I understand that a GUI has been written – very likely the same function that I’m doing. I’ve never seen their code. In fact I haven’t heard from Andrew Rawnsley since I sent him the core code and instructions. I have to assume that no news is good news.

I’m also assuming, rightly or wrongly, that the ARMini GUI is something that R-Comp will keep to themselves. The GUI I’m writing will be available to everybody.

I thought that

quote: “the BB is modified, the OS and disc build are customised, but we’re feeding changes back into the source tree for others to benefit from”

so why re-invent the wheel? Hopefully we’re not going down the split OS road again, are we?

As far as I am aware, the reflashing GUI is not part of the RISC OS source tree. I believe it to be something that R-Comp have commissioned.