Towards BeagleBoard "CMOS RAM"

Interesting. I’d been wondering whether it’s a softload.

That would make sense, I see. However: shouldn’t something that lets you update and interfere with the OS and how it works be part of the OS itself rather than a closed source third party app?

@Peter:

The code I use to send CMD3 is:

WaitForCMDI ();
write_word (MMCHS1_ARG, 0);
write_word (MMCHS1_IE, 0x100F0001);
i = SendMMCCommand (CMD3);
printf ("Result of CMD3 is %d\n", i);
printf ("CMD3 gives status %08X\n", read_and_clear_stat ());
uiDump = read_word (MMCHS1_RSP10);
printf ("CMD3 gives response %08X\n", uiDump);
uiRCA = (uiDump >> 16) & 0xFFFF;
printf ("RCA = %08X\n", uiRCA);

I also have CMD3 as 0×031A0000.

The above code, and more, is part of RO5 nowadays, so you can get it all from the ROOL web site. In the above I have restored the printf diagnostic statements.

Yes, I have seen your code.
When I try to do the same in a simple program I just get an timeout (just writing to _ARG and _CMD).

I try this from a deskop program on the BB. The SD interface is in a ‘stable’ state at that point isn’t it?

The SD interface is in a ‘stable’ state at that point isn’t it?

I would have thought so, but I have never tried issuing CMD3 on its own. I have always started right from the beginning – resetting the interface, identifying the card type, etc. This makes it unlikely that I can help you.

I’m never very sure about the states and state transitions of SD cards, but the “Physical Layer Simplified Specification Version 2.00” that I’m reading suggests that the card must be in either Ident or Standby state prior to receiving CMD3, and will be in Standby state afterwards.

Ah, I never paid any attention to the different states. Do you know a command you can issue from the current state?

Just to clarify things…

The actual flash code we use is from Dave Higton (with big thanks). However, we have commissioned our own application which provides the front end, manages the installed versions (to allow rolling back to previous version(s)) and tracking of what is installed so that only the correct actions are available to users. It also provides on-screen instructions and changelogs and various other niceties. It is distinctly a standalone application, and not part of the OS in any way.

We also provide a similar tool (although the more elaborate version hasn’t made it to release yet) for managing CMOS settings.

One of the areas we feel we can excel in making the user experience better for our customers. Front ends tend to get forgotten about in RISC OS sometimes, so things may not be as user-friendly as they could be. As such, we’ve done quite a bit of work on trying to improve this experience to make ARMini as nice as possible to use.

There are numerous other examples of additional software applications that we developed for ARMini (eg. screen mode stuff, support for up to 1920×1200, drive icon enhancer, desktop FAT32 formatting, amongst other things). These are all standalone components which are part of the ARMini package, but not part of the OS.

Don’t worry, however, the OS changes from ARMini are feeding back into the build for those of you who aren’t ARMini customers. For example, you’ve gained improved video stuff, smoother desktop, significant improvements on the USB front, esp via mUSBdriver and so on. As usual – HUGE thankyou to Jeffrey, without whom none of this would have been possible. Hopefully additional stuff will be happening soon, too, that everyone will benefit from.

So, have no fear, there’s no “branching” going on. Just that those who choose to support the ARMini project receive extra stuff that we develop. They also get access to the private ARMini download site with additional software, upgrade packs and so on. I think everyone would agree that we should provide these extras to those who support us (and in turn, our RISC OS software development) via ARMini. So far, all my profits have been fed into further development. That’s how the RISC OS world works.

screen mode stuff, support for up to 1920×1200, drive icon enhancer, desktop FAT32 formatting

Call me traitorous, but I can’t see any way in which any of the items in the above list could possibly be honestly described as anything but part of the OS.

In what way are “support for up to 1920×1200” or “desktop FAT32 formatting” (especially) “not part of the OS”?

Thanks for clarifying things Andrew. The last thing we needed was a 3rd fork of the OS!
Have the OS changes from the ARMini been fed back into the RISC OS Open CVS yet?

I currently have a Beagleboard XM, but I am seriously thinking of buying an ARMini, so don’t be suprised if I get in touch soon!

In what way are “support for up to 1920×1200” or “desktop FAT32 formatting” (especially) “not part of the OS”?

I’d guess that the 1920×1200 is an MDF, and Andrew talked about writing frontends, so the desktop FAT32 formatting is probably a frontend to FAT32Format rather than something built into the OS.

Yes, all the OS changes are done in conjunction with Jeffrey/ROOL. The only outstanding change which I feel is “core OS” is the updated Keyboard configure plugin Res file, and I have only held that back because it was hard finding common ground on the wording, so I went with what I was comfortable with for ARMini users.

Just to be clear, the “OS” is rather loosely defined in our licence, but I take it to mean the ROM, plus associated disc components as available on the ROOL website. I think this is suitably broad, and tallies with my conversations with John Ballance.

Finally, remember that we’re also licenced with RISCOS Ltd to ensure everyone is happy, so if anything, we’re trying to heal rifts/forks, but to be fair, it’s not an easy problem to resolve.

Ref Rob’s posting, remember we offer a trade-in for your XM at full value, if you wish.

My flasher application is written to support all four files on the bootable SD/SDHC/MMC card: Boot.scr, Cmos, riscos and Uenv.txt. I’m putting in some file size limits in the hopes of protecting against manifestly silly files. Cmos is currently 2052 bytes, and we can imagine it might go up to 8 kiB one day, so I’m thinking of limits of 2052 and 8196 bytes. riscos is currently 4 MiB, but might one day grow larger, so I’m thinking of limits of 4 MiB and 6 MiB.

Boot.scr is currently 120 bytes. It’s not so easy to see what variation there might be. Maybe 100 bytes to 200 bytes?

Similarly, Uenv.txt is currently 65 bytes, and I am also unsure of what variation there might me. How about 50 bytes to 90 bytes?

Any suggestions or comments would be welcome.

The app is written in BASIC, with the core flasher code written in C and running in a taskwindow. The file size limits are within the first few lines of RunImage, could be altered by anybody in an “emergency”, and will be supported by me for the foreseeable future.

I guess the CMOS file could have it’s checksum checked to see if it’s valid, although this probably only affects the first 239bytes, not the rest of the extended CMOS.

Well, the good news is that the flasher app seems to work as I intended. Just need to make a !Help file and I can release it.

Any comments as to the possible lengths of the files (2 posts above) would be welcome.

What about the files ‘MLO’ and ‘u-boot.bin’? Earlier versions of these required a ‘user.scr’ file and there are also files such as ‘ramdisk.gz’, ‘ramfs.img’ and ‘uImage’ for the Linux disto?

About the file lengths, you idea looks good. Not to small and not to large.

If you don’t want to release a new version, you could write the values in a ‘config’ file.

Is the intention to allow the flasher tool to prepare new cards, or only to update existing ones? If it’s going to be able to prepare new cards then you’ll need to have support for the MLO & u-boot.bin files.

If you haven’t already, I’d recommend taking a look at the SDCreate source/docs. There are actually quite a few different combinations of files needed depending on board type. You’ll also be able to see the different size checks that I do on the files.

Is the intention to allow the flasher tool to prepare new cards, or only to update existing ones?

Both.

If it’s going to be able to prepare new cards then you’ll need to have support for the MLO & u-boot.bin files.

I don’t understand. I created a card yesterday, from blank, put just the four files I named on it, and booted from it.

Are MLO and u-boot.bin only needed for Linux?

Are MLO and u-boot.bin only needed for Linux?

They’re needed for boards which don’t contain x-loader/u-boot in NAND. E.g. BeagleBoard-xM & TouchBook.

Ah, OK. I’ll modify the app accordingly.

Thanks!

I’ve got lots of dprintf statements throughout my code, which haven’t been executed in ages. Now I need them to work, I have this vague memory that I need to do something to enable dprintf statements to work at all. Can someone please remind me what it is, or alternatively suggest why none of them appears to generate any serial debug output?

Please ignore my noise – I’ve found my central debug on/off switch.

Assuming you’re talking about the code in the HAL – OMAP3.h.common, uncomment the “#define DEBUG_ENABLED” line near the bottom of the file.

Yes, thanks, Jeffrey, found it. I guess our postings must have crossed.

Taking a lesson from the command line Linux distribution bundled with the Beagleboard XM is there a case for another file on the SD card (which would probably be a bit larger, say 60Mbytes or so) which would be loaded into memory in a similar way to ‘cmos’ but used to initialise the RAM disc with a pre-built boot structure (given the appropriate CMOS setting for the boot drive being the RAM disc). The purpose is to attract new users to a fully functioning RISC OS environment but without the need for an external RISC-OS-formatted drive with a boot structure. It could even be bundled with the Beagleboard XM (seleccted by holding down the USER button) if the beagleboard.org people play ball.