Towards BeagleBoard "CMOS RAM"

Probably not. This isn’t the first time I’ve seen errors claimed to be caused by inadequate system heap space – the previous one being when de-tarballing. I cannot ever recall seeing that error before, in all the time I’ve used RISC OS since RO2 in the A3000, until I started to use a recent image of RISC OS on the BB.

It may also be worth mentioning that I normally run with some RAM disc present. I may be less likely to get the error if I quit the RAM disc. However, that association is uncertain.

Shouldn’t there be something in a4 – “kernel workspace ptr”? Where do I get that from?

That value is actually unused at the moment. At some point I’ll get rid of it.

I’ve been having an “interesting” time calling that code. I made it into a back door in my NVMemoryRead code (call with length <= 0 and it calls the above code instead). It works sometimes – depending on what lines of code follow the call.

The code seems to work fine for me. What happens when it fails – does it return zero or nonzero? If it returns zero, has it actually updated the contents of the rtctime struct?

Also remember that it’ll only return zero if the RTC is running, and (AFAIK) the only time RISC OS will start the RTC is when OS_Word 15 is called.

The code seems to work fine for me.

Sometimes it works fine for me too.

What happens when it fails

Bad OS_Hardware reason code

Postmortem requested
Arg2: 0×0000e2d0 58064 → [00000000 00000000 0×313a3431 0×32353a31]
Arg1: 0×0000e2d4 58068 → [00000000 0×313a3431 0×32353a31 00000000]
fc141604 in function GetDOSDateAndTime
9a9c in function main
Arg2: 0×0000808c 32908 → [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcd11]
Arg1: 0×0000e58c 58764 → [0×49534353 0×61483a3a 0×69446472 0×2e346373]
fc131ab0 in shared library function
b9cc in anonymous function

Remember: whether it succeeds or fails depends on what code follows the call to GetDOSDateAndTime.

How are you calling the code? I can’t see any way for it to trigger a “Bad OS_Hardware reason code” error unless (a) you’re passing in a bad reason code or (b) you’re doing something to cause stack corruption.

My apologies for the noise – I had completely forgotten that I have to set R8 to 0 before making the call.

No problem!

There’s no way of knowing, at HAL level, whether DST is in force, is there?

No, there isn’t.

While reading and writing the SD card the MMCHS_RSP10 register becomes &0900 and sometimes &0C00. The later is an error (I think) but is &0900 correct or am I doing something wrong?

is &0900 correct or am I doing something wrong?

That would depend on what you’re doing.

I try to read and write multiple sectors (CMD18 and CMD25). CMD25 (write multiple sectors) gives in MMCHS_RSP10 &0900. After this I have to do have to send a Stop command (CMD12). This returns &0C00.
I can not find the meaning of the bits. Is it the R1 responds? Does &0900 means I have a CRC error and it is in Idle state?

As far as I can see, CMD18 and CMD25 return an R1 response, and CMD12 returns an R1b response. R1 and R1b are almost identical. It looks like bits 12:9 are the current state, and bit 8 is READY_FOR_DATA.

My notes indicate that I didn’t much care about the contents of the RSP10 register. Also I’ve never used CMD18, CMD25 or CMD12; I only read and write single blocks. This means I don’t have much help to give, you, I’m afraid.

It looks like bits 12:9 are the current state, and bit 8 is READY_FOR_DATA.

Can not confirm that. If this is the case the &900 responds means:

00001001 00000000


bit 8 high = READY_FOR_DATA

bit 11 high = Illegal command?

Hmm, that doesn’t look right. Anyway, Multiple read and write seems to work now. But reading the CSD and CID register gives a conflict on MMCI_CMD lines.

bit 11 high = Illegal command?

Not as far as I understand it. The state is in 12:9 (not 11:8, which would be easier to read!), so the state is 0100 = 4.

If I understand correctly, of course.

bit 11 high = Illegal command?

Not as far as I understand it. The state is in 12:9 (not 11:8, which would be easier to read!), so the state is 0100 = 4.

I found this:

Bit 0: The card is in the idle state and is initializing.
Bit 1: An erase sequence was cleared before executing the command because an out-of-erase-sequence command was received.
Bit 2: An illegal or unsupported command code was received.
Bit 3: CRC error.
Bit 4: An error occurred in the sequence of erase commands.
Bit 5: The device received an address that doesn’t match the expected block length.
Bit 6: The command’s argument was out of range.
Bit 7: Always zero.

If all went well the value should be zero. So I don’t understand what &0900 means. Value 0100 : bit 2 is high => illegal command???

After reading the datasheet again and looking at websites it looks like RSP0 holds Command Response[23:8]. The end bit and CRC are skipped. The R1 byte should be located at the bottom bits of the RSP0 register so the value of &0900 give a responds R1 of 0 (which is good).

Last night I successfully wrote a file to an SD card. This brings me one step closer to being able to reflash RISC OS without removing the card.

Next steps are to be able to re-write a file, and to deal with that dratted FAT12 format, which is substantially harder than FAT16 and FAT32. I hope to have more news soon.

After all that is working, I will be able to extract parts of the code to make the “CMOS RAM” writable.

That’s great news Dave, thanks for your continuing hard work on this!

While testing the SD interface I also tripped over the FAT12 format.
Couldn’t we drop FAT12 and switch to FAT16 or FAT32 for the micro SD card?

Couldn’t we drop FAT12 and switch to FAT16 or FAT32 for the micro SD card?

If you can work out how to make a FAT16/FAT32 image which fulfills the following criteria, then I’ll be happy to use it:

1. Small (Remember that it only needs to store about 5MB of data, so anything above that will just waste space on the card and slow down the image creation process)
2. Recognised as bootable by the OMAP’s built-in bootloader
3. Works properly with x-loader & u-boot (although they’re less finicky than the ROM bootloader)
4. Works properly with DOSFS (which is the problem I had last time I tried this)

Small (Remember that it only needs to store about 5MB of data, so anything above that will just waste space on the card and slow down the image creation process)

The other way of looking at it is that to format it small wastes all the remaining space – it’s inaccessible, and I can’t see any way of ever recovering it. Also there is no good reason to blank all the data space; the only things that must be written are the FATs and the root directory. I don’t know whether it’s possible to tell the formatter not to blank the data space, though.

I do recognise all your other criteria as important.

I wonder what’s wrong with DOSFS? I couldn’t see anything wrong with the image you sent me when we were looking at this last time.

The other way of looking at it is that to format it small wastes all the remaining space – it’s inaccessible, and I can’t see any way of ever recovering it.

Recovering the space is easy, surely? Just create a second partition. Assuming we find the time to add partition support to RISC OS ;-)

Also there is no good reason to blank all the data space; the only things that must be written are the FATs and the root directory. I don’t know whether it’s possible to tell the formatter not to blank the data space, though.

Remember that SDCreate doesn’t do any formatting itself; it just copies a pre-formatted blank image onto the card. If SDCreate was smart enough to understand the FAT format (or if DOSFS was able to format arbitrary partitions instead of just floppies) then it should be easy enough to produce a tool which only writes the necessary bits of data. Or to write a tool which creates a FAT32 partition that fills the card.

I’m not at home to test this, but won’t FAT32Format by Jeff Doggett allow you to format the card to whatever version of FAT you wish? If this was bundled with SDCreate, it could (optionally) format the card and then write data to it.

i seem to remember that when you had a pccard in a rpc you created a file to use as a partition for dos/windows is it possible to use the same approach, or am i barking up the wrong tree???

i forgot to say use the rest of the sdcard for this file