Towards BeagleBoard "CMOS RAM"

I’m looking at the steps necessary to support a functional equivalent of the CMOS RAM that we’re all used to and we all rely on.

Firstly, as we all know, 256 bytes aren’t enough, so I propose that any equivalent is longer – at least 1 KiB. Presumably the HAL would be able to tell the size, though ATM I don’t know how.

Secondly, it seems to me that a useful first stage would be to split the CMOS RAM contents out as a third file on the SD/MMC card. Currently the part of the boot script that I understand is:

fatload mmc 0:1 0x81000000 riscos
go 0x81000000

OK, so why don’t we call the file “cmos”, and add an extra line in the boot loader:

fatload mmc 0:1 0x81000000 riscos
fatload mmc 0:1 0x85000000 cmos
go 0x81000000

The address 0×85000000 is a total invention of course.

That would at least allow someone to start with CMOS contents different from the standard distribution without having to rebuild code. It also lays the foundation for non-volatile storage of CMOS data.

Thirdly, I presume that the OMAP’s ROM contents include the ability to write to the SD/MMC card, not merely read from it; can anyone point me at documentation of the ROM, please?

Secondly, it seems to me that a useful first stage would be to split the CMOS RAM contents out as a third file on the SD/MMC card.

Agreed. In fact, this is pretty much the only option available for the BB-xM, unless people start attaching their own EEPROMs to one of the spare IIC busses.

OK, so why don’t we call the file “cmos”, and add an extra line in the boot loader:

fatload mmc 0:1 0x81000000 riscos
fatload mmc 0:1 0x85000000 cmos
go 0x81000000

I’d like it if there was a way for the bootloader to pass parameters to the OS to indicate where the CMOS data is in RAM. The easiest way to do this would be to start packaging the ROM images as u-boot uImages, so that u-boot treats it like a Linux kernel and passes in a parameter string on entry. This has actually been supported for a while, and I’ve got a rough unreleased RISC OS port of the u-boot mkimage tool (for converting ROMs/kernels to uImage format), which with a little bit more testing can easily be put into the build system. So then the only remaining bit would be to update the HAL to parse the parameter string and determine where the CMOS file has been loaded (and later determine other things, e.g. where the file should be written back to).

Thirdly, I presume that the OMAP’s ROM contents include the ability to write to the SD/MMC card, not merely read from it; can anyone point me at documentation of the ROM, please?

The OMAP ROM only has the ability to read from the card. I’m not sure if TI have released any full documentation for the OMAP ROM, but AFAIK there are only two purposes it serves – to act as the initial bootloader, and to provide a handful of system calls to allow the OS to perform any activities that require the CPU to be in secure mode.

You may be confusing the OMAP ROM with u-boot – remember that in a typical setup an OMAP system uses three bootloaders: the OMAP boot ROM, x-loader, and u-boot. u-boot is the one that executes the boot script. It also has support for a large number of filing systems and storage devices (although whether full support for all systems will have been compiled in is another matter). u-boot does support writing to flash memory, but I’m not sure if it supports writing to SD cards. And when RISC OS starts it will wipe u-boot from memory anyway.

A better idea than attempting to rely on u-boot or ROM code would be for us to just pull our collective fingers out and finally write an SD/MMC driver for RISC OS. Even if we just start off with some bare-bones code whose only purpose is to locate the sector containing the CMOS file and overwrite it with new data, it’ll still be better than nothing.

A better idea than attempting to rely on u-boot or ROM code would be for us to just pull our collective fingers out and finally write an SD/MMC driver for RISC OS.

OK…

The register addresses I see in the OMAP35x TRM (such as 0×48004A00, 0×4809C014, etc.) – are they mapped in at those addresses in RISC OS? Presumably all the code has to be in SVC mode in order to access them?

(I have no idea whether I will be able to do any of this, but it might just be worth a try.)

The register addresses I see in the OMAP35x TRM (such as 0×48004A00, 0×4809C014, etc.) – are they mapped in at those addresses in RISC OS?

Nope. You’ll want to use OS_Memory 13 to map in the memory.

Presumably all the code has to be in SVC mode in order to access them?

Yes, unless you specify different access privileges. Access privilege of 0 should give you full read/write access in user mode, so calling with R0=13+(1<<17) should make testing a bit easier.

(I have no idea whether I will be able to do any of this, but it might just be worth a try.)

Apart from the releveant bits of the OMAP TRM you’ll also want to look at the SD card simplified specification which contains details of the SPI protocol that’s used to talk to SD cards. (There are other, better, protocols available, but for details of those we need to pay lots of money to the SD Association, which I suspect isn’t going to happen any time soon)

Just struggling with how to access location 0xF9804A10 from C…

Just struggling with how to access location 0xF9804A10 from C…

Either write some functions/macros to read/write words/bytes, or create a struct that matches the layout of the registers you’re interested in. I tend to prefer the struct approach, but the function/macro approach might be easier since there’s less chance of making mistakes and accessing the wrong addresses.

How about these for some simple macros:

#define READ_WORD(addr) (*((unsigned int *)(addr))
#define WRITE_WORD(addr,value) (*((unsigned int *)(addr)) = (value)
#define READ_BYTE(addr) (*((unsigned char *)(addr))
#define WRITE_BYTE(addr,value) (*((unsigned char *)(addr)) = (value)

Once the unbalanced parentheses are sorted out, that works fine, thank you very much! :-)

Well, I’m slowly building some code to use, implementing the OMAP35x TRM section 22.6.1.3 (page 3133 onwards).

It’s worrying, though, that, as soon as I do the operations in Table 22-8, the BeagleBoard’s screen goes black and nothing responds any more.

It’s worrying, though, that, as soon as I do the operations in Table 22-8, the BeagleBoard’s screen goes black and nothing responds any more.

Probably because you’ve turned off a bunch of important clocks :)

The SD/MMC section of the manual may not make it particularly clear, but the PRCM.CM_ICLKEN1_CORE & PRCM_CM_FCLKEN1_CORE registers control more than just the SD/MMC clocks. So to avoid killing something important you’ll need to use a read-modify-write sequence to only update the bits you’re interested in (i.e. bit 24 of each register).

The SD/MMC section of the manual may not make it particularly clear, but the PRCM.CM_ICLKEN1_CORE & PRCM_CM_FCLKEN1_CORE registers control more than just the SD/MMC clocks. So to avoid killing something important you’ll need to use a read-modify-write sequence to only update the bits you’re interested in (i.e. bit 24 of each register).

Ah, yes, that’s much less dead :-) Thanks again!

Hi Dave, can you tell about your progress up to now? (or send sources to uwe at familie-kall in germany).

Do you have some structure in mind or sources you want to take parts from?

I tried to reach the SD/MMC using BASIC before I had the compiler and in an early stage of the kernel but finally got my Norcroft compiler.

Hi Dave, can you tell about your progress up to now? (or send sources to uwe at familie-kall in germany).

I’ve sent an e-mail to what I believe is the correct decode of that address.

I tried to reach the SD/MMC using BASIC before I had the compiler and in an early stage of the kernel but finally got my Norcroft compiler.

My code uses Norcroft.

Great, thanks.

Norcroft is what I intended to use, too.

Norcroft is what I intended to use, too.

If you don’t already have it installed, note that the installer isn’t ARMv7 compatible . However, the tools work when transferred from another RISC OS machine .

Edit: There has been talk of enlisting some help from Kevin Bracey (who may also be able to help with Jeffrey’s proposed debug symbols ). (I guess this work might require finance .)

I used it for adding the davicom usb-ethernet adapter to etherusb and did this on the beagleboard (unsecessfully up to now), but building/compiling was not the problem.

I remember though, that at some point during the riscos build there was a remaining issue but I cannot remember what it was.

Did anybody ever build riscos on the beagleboard successfully till then?

Did anybody ever build riscos on the beagleboard successfully till then?

Till when?

I think it was in may. But I read your post in the other Thread , thanks. By the way, the filetype error of the trinity file is still there afaik.

Did you unpack on a usb stick or using a card reader or RAM? You had a revC I presume?

I’ll see if the Trinity error reoccurs when I’m next able to test.

I’m not sure whether the unpacking was using a card reader or the RAM disk, but the USB stick was FAT formatted for transfer from a laptop (for when the BB wasn’t networked/before it was configured) so it wouldn’t have been that.

Yes, mine’s a rev.C. You’re an early adopter with a rev.B, aren’t you?

I’ve just experienced my first “Broken directory” error on the BeagleBoard. Which directory was broken? The one with my SD/MMC app in it. The “Recovered” file contains very little of the source.

Last backup was 3 days ago. That contains rather more.

Bad luck, Dave – isn’t it always the way!?

Bad luck, Dave – isn’t it always the way!?

I suppose it is :-(

The worry is that my code may have caused the broken directory.

The OMAP35x Technical Reference Manual is 3549 pages long. I can’t possibly absorb all that knowledge in a short time, if ever at all.

The OMAP35x Technical Reference Manual is 3549 pages long. I can’t possibly absorb all that knowledge in a short time, if ever at all.

You think I know it all off by heart? The trick is to only read the chapter(s) that you need to for the driver that you’re currently writing.

AFAIK the SD/MMC hardware doesn’t contain a DMA controller, so the only way your driver could cause a broken directory is if your code writes over random memory or manages to stiff the machine while something else is writing to disc.

Yes, mine’s a rev.C. You’re an early adopter with a rev.B, aren’t you?

Yes – grmbl. But someone had to start with Hardware – and to ‘warn’ the others to wait for revC :-) So I’ll wait for the XM! or a Pandora?

AFAIK the SD/MMC hardware doesn’t contain a DMA controller, so the only way your driver could cause a broken directory is if your code writes over random memory or manages to stiff the machine while something else is writing to disc.

That could be a hint to the seemingly higher safety when working with card reader / SD card instead of a usb stick. The card reader might generate the timing when writing to SD more independently. Just a thought. (Sorry, it’s a little off-topic for this thread)

Hmm. Looks like most of the stuff in my “Recovered” file was written by NetSurf.