Towards BeagleBoard "CMOS RAM"

Will SWI OS_Memory be available when HAL_Init and HAL_NVMemoryRead are called for the first time? I need to call it to translate the addresses of the SD/MMC interface registers.

I’m just beginning the (probably long) process of adding the global variables and initialising them ready for calls by the SD/MMC code.

Btw I just ordered an MMC card today, because I’d like to try to make the code read and write MMC too. It’s only 64 MiB, so formatting as FAT12 is realistic :-) Two birds with one stone, maybe.

Dave, Did you make any consideration of putting the fake CMOS in a reserved sector as detailed in the last post of page 3 of this thread. It should considerably simplify your task: no FAT to interpret, no danger of people deleting the file by mistake, no long file names, no worry about locking with SCSIFS using the card too, amongst other simplifications.

Will SWI OS_Memory be available when HAL_Init and HAL_NVMemoryRead are called for the first time?

Dave, unless I’ve misunderstood you, you probably want RISCOS_MapInIO.

Dave, Did you make any consideration of putting the fake CMOS in a reserved sector as detailed in the last post of page 3 of this thread. It should considerably simplify your task: no FAT to interpret, no danger of people deleting the file by mistake, no long file names, no worry about locking with SCSIFS using the card too, amongst other simplifications.

I have zero confidence that anything recorded in a reserved sector of a flash device will remain accessible. If you’ve looked at as many flash devices as I have, at sector level, you’ll know that the numbers of reserved sectors varies widely. Why are they reserved? There has to be a good reason to reduce the amount of storage that’s available to the end user.

In any case: (a) I prefer that users have access to the information in the form of a file; (b) I’ve done the FAT work now (other than the little extra bit to deal with the small differences in FAT12) so there’s nothing to gain.

Like others, I’ve been following all of this with great interest. It’s wonderful to hear that you’re getting somewhere with this, Dave. Thanks :-)

It’s wonderful to hear that you’re getting somewhere with this, Dave.

I genuinely feel optimistic at the moment, although it is taking a long time. I’m continuing to learn, which is always enjoyable.

Dave, unless I’ve misunderstood you, you probably want RISCOS_MapInIO.

I’ll take Jeffrey’s advice on this. It was he who advised me to use OS_Memory originally, and he who last updated the RISCOS_MapInIO page, so I regard him as the expert – or maybe even the ultimate authority!

I’ll take Jeffrey’s advice on this.

And my advice – in this situation at least – is to use RISCOS_MapInIO, for a couple of reasons:

• Although I can’t immediately find a reference to it in the documentation, I’m fairly certain that the docs say that the HAL shouldn’t use SWIs. Or at the least, the HAL should be OS-agnostic, which means that even though it could use SWIs if the host OS supported it, at present the HAL has no way of knowing which OS it’s running underneath and thus has no idea when it is/isn’t safe to use SWIs, or even what SWI numbers and calling conventions to use for specific tasks. Maybe this is just an unwritten rule that I’ve picked up (after all, if HAL is allowed to use SWIs then what’s the point of RISCOS_MapInIO and RISCOS_IICOp?)
• During HAL_Init I’m not sure whether the SWI dispatcher is actually up and running yet.

And my advice – in this situation at least – is to use RISCOS_MapInIO

Right ho, Jeffrey, I’ll try it. Thanks again, and thanks to WPB for steering us in the right direction.

thanks to WPB for steering us in the right direction.

No probs. Like Trevor said, I’m following this thread with interest. Thanks for the work you’re putting in – having CMOS will be a major leap forward for the OMAP port. And I’m also quietly chipping away at getting the WLAN module on the IGEPv2 working (extremely slow progress; nobody hold their breath, please!), which is SDIO-connected, so heavily related to this work.

which is SDIO-connected

Interesting! Can you point me at any inexpensive SDIO device, please? The initialisation stuff I struggled with should be capable of identifying an SDIO device, so I’d rather like to try, if I can get hold of something cheaply.

Can you point me at any inexpensive SDIO device, please?

Sorry, I can’t. Maybe someone else here can? This is the first SDIO device I’ve encountered.

The initialisation stuff I struggled with should be capable of identifying an SDIO device.

Yes, as far as I can see, the init of the MMCHS module should basically be the same until after you send CMD5, when you should get a result back that distinguishes SDIO cards from regular SD cards. At that point, I have to jump into a whole load of secondary initialisation code (only partially written ATM). I was struggling with just powering the card at first as the ISEE documentation is woefully lacking and the Poky Linux firmware I have as default on my board was setting things up wrongly anyway, but I think I’ve got that figured now. Currently I’m trying to find out what frequency I should be setting SYSCTL.CLKD for this card. I suspect I’m going to have to try to glean it from the Linux sources as the answers don’t seem to lie anywhere else!

Well, I’ve made another tiny bit of progress this evening. It took me hours to work out how to call an OS entry (if it’s docmented anywhere, I can’t see it), and the notion that v8 is pointing to the base of OS entries turned out not to be true at the point where I called it. But a bit more digging enabled me to find how it should be set.

So I’ve got a logical address (&F9E9C000) for the base of the MMCHS1 registers. It looks plausible, but: when I was using OS_Memory, running as an application, the address was &F989C000.

• Should I be concerned that they are different?

• Will the address returned by OS_MapInIO remain valid until shutdown?

Another question: how does one calculate the header information of the boot script? I tried adding another line, but the bootloader sees the boot script as corrupt, having a wrong “crc”, and won’t boot.

The reason I ask is that I can see an elegantly simple way to boot with the CMOS contents determined by a file at boot time. Just as suggested in the first message of this thread.

how does one calculate the header information of the boot script?

Can that question – I’ve discovered the power of mkimage and the Obey file in !SDCreate.

Yay. My BeagleBoard now boots with !Alarm displaying in a user defined mode.

It took me hours to work out how to call an OS entry (if it’s docmented anywhere, I can’t see it), and the notion that v8 is pointing to the base of OS entries turned out not to be true at the point where I called it.

Strangely enough, I don’t think that really is documented anywhere! But you should have been able to work it out fairly easily by looking at some of the other HAL sources :)

Should I be concerned that they are different?

No. The fact that you’ve got a different address when running in the HAL is simply because other bits haven’t had a chance to map in their own IO memory yet (I think the IO address space is allocated downwards from &FA000000, in a first-come, first-served manner).

Will the address returned by OS_MapInIO remain valid until shutdown?

Yes.

Yay. My BeagleBoard now boots with !Alarm displaying in a user defined mode.

Excellent! Will you be sticking with that method? If so then I’ll do what I said I was going to do ages ago and update the HAL so that it can parse the boot arg string that u-boot passes to uImages.

Also I’m a bit surprised that you managed to get that to work at all – do you load the CMOS file into SRAM or something? Beware that the HAL temporarily stores a copy of the board config struct there so that it doesn’t get clobbered during the RAM wipe & MMU initialisation.

Will you be sticking with that method?

It’s only a temporary solution, which we discussed at the beginning of this thread. It allows me, or anyone else who uses it, to have custom CMOS contents – it’s somewhat laborious to change them, but the point is that now it can be done.

Work on the full solution will continue.

Also I’m a bit surprised that you managed to get that to work at all – do you load the CMOS file into SRAM or something?

The trick is to load it into the last 2 kiB of the HAL, and copy it from there on initialisation into my cache.

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

Simples!

There is an interesting bit of compatibility by good fortune: the copy to cache can be left there, and if the cmos file isn’t loaded, the cache will be full of zeros, which is the same result as before.

Did I have to make a change to enable serial debug output? I no longer need it and I’d like to turn it off. If I actually had to turn it on, that is. Oh, to have a memory (between the ears, that is…!)

I ought to be able to look it up from the ROOL wiki, but I seem to be getting mainly empty pages and “500 Internal server error” pages at the moment.

There’s the DebugTerminal in Kernel.Hdr.Options, which controls whether the serial terminal is used (i.e. keyboard input taken from serial, character output sent to serial). That option’s obviously off by default. All the other debug output that an ordinary OMAP3 ROM image has (the bits the HAL prints on startup, the list of modules as they’re initialised, etc.) is all currently on by default and shouldn’t really be anything to worry about.

There’s the DebugTerminal in Kernel.Hdr.Options, which controls whether the serial terminal is used

That’s the one – thanks again, Jeffrey.

The FAT format allows sectors to be set aside for system use (the simplest example being a boot sector, but others can be reserved by setting the appropriate counts in the BIOS parameter block).

Could this method be used to allow an ADFS partition to exist on a DOS style parttioned drive, in a way that a current machine could read?

I am thinking of what happens when partition support is added, how machines with RISC OS in ROM could softload. (So perhaps a new thread should be started for any reply)

Could this method be used to allow an ADFS partition to exist on a DOS style parttioned drive, in a way that a current machine could read?

It’s dangerous. I’ve read, within the last few weeks, references to the sector at byte address &C00 being used for extra information for FAT-formatted discs. That’s the ADFS boot sector. If that gets blatted, all is lost. (If you want references, sorry, my memory is not specific enough.)

Although there is no authority in charge of assigning disc format identifiers for use in partition tables, I still feel that a conventional primary partition scheme is the best way forward for putting RISC OS on a partitioned disc. Then the bootloader needs to look for a primary partition of type RISC OS, then look at the sector at byte address &C00 within that partition as the RISC OS boot sector.

The trouble with reserving sectors is that it’s rather Shavian logic: they’re reserved so that anyone can use them as they wish. There is no controlling authority. There is nothing to prevent a clash of different uses. Non-reserved sectors in a recognised disc format, by contrast, have to be used according to the rules of that disc format.

I still feel that a conventional primary partition scheme is the best way forward for putting RISC OS on a partitioned disc. Then the bootloader needs to look for a primary partition of type RISC OS, then look at the sector at byte address &C00 within that partition as the RISC OS boot sector.

I agree totally, however if you need to softload from an old version of RISC OS, how would you do it?

From plugging in DOS partitioned drives, I’m pretty sure you can’t use the conventional format with current RISC OS systems, (apart from perhaps adjust).

If RO5 is to be used on a 3.7 system, for example, to be sensible it would need a more modern disk format than the old ADFS.

This means an old adfs partition to boot from, plus a more modern partition to run RO 5 from.

Could the conventional PC partition system be contrived to work in this situation, or would a different solution be required? (even if it is just displacing the PC system to the end of the adfs area, obviously not expecting it to work on other systems)

Would we need to get a partition type assigned?