Towards BeagleBoard "CMOS RAM"

How do I call a HAL function from within the HAL?

Just like you’d call any other function. HAL functions are APCS compliant, so if you’re calling from C all you’d need to do is declare the appropriate function prototype and then just make the call. The HAL entry point pages on the wiki should have the appropriate prototypes to use for each HAL call.

Of course functions which aren’t HAL entry points might not be APCS-compliant, so be careful if you’re going to try calling any of those.

I called HAL_CounterDelay from my C with an argument of 1000. It didn’t appear to return. I can’t see that the HAL_CounterDelay code does anything that it shouldn’t; it alters a1-a4 and ip, which are all permitted by APCS-32.

More experiments tomorrow.

For HAL_CounterDelay to work, the timer which it relies upon (GPTIMER2) needs to be running. GPTIMER2 gets exposed to RISC OS as HAL timer 0, i.e. the 100hz ticker. Looking at the kernel source, it looks like the timer will be started immediately after HAL_Init returns. So if you’re trying to call it after HAL_Init (e.g. from within the NVMemory functions) then everything should work OK. But if you’re trying to call it from inside HAL_Init then you’ll need to do it somewhere between the call to PRCM_SetClocks and the call to Timer_Init, because that’s the only time the timer will be running.

But if you’re trying to call it from inside HAL_Init then you’ll need to do it somewhere between the call to PRCM_SetClocks and the call to Timer_Init, because that’s the only time the timer will be running.

Once again, Jeffrey, thanks. That’s the fundamental logical error that hadn’t occurred to me.

I’ve removed the call from HAL_Init, and we’re running again.

Rats. I’ve bent that pin in my BB’s SD/MMC connector again.

That’s slowed development down. Just as I was beginning the FAT-reading stuff, too.

Just a thought, how about using a mini/microSD card with adaptor? You could then leave the full-sized adaptor card in the socket and just remove the mini/micro card from it as/when necessary (adaptors are cheap to pick up, so have one in the BB and one in whatever else you use)? It would help reduce wear and tear on your already fragile socket.

Just a thought, how about using a mini/microSD card with adaptor?

Yes… I just need a whole new set of cards!

I did see a full size extender, but it was in the ball-park of GBP100, so I declined.

eBay has an extender on a cable for around £6 inc postage from China!

eBay has an extender on a cable for around £6 inc postage from China!

Have you seen any shorter than 50 cm? I can’t imagine one that long could possibly work. The signal at the destination end would be drastically different from that at the sending end, and probably from what a real device could cope with. Plus both ends appear to be sealed, which makes shortening it a real challenge. Mind you, at that price, there’s not much to be lost in an unsuccessful effort!

Phew. Although the pin broke (not merely bent), it’s one of the front row, so electrical contact isn’t a necessity for what I’m doing. I managed to bend it far enough out of the way for now.

But I really am drinking at the Last Chance Saloon this time.

Yup, got the MBR…

Have you seen any shorter than 50 cm?

No, that seems to be the only one out there.

... and the VBR of the first partition.

Looks like I’m losing another USB stick. That makes three now that don’t react fast enough for RISC OS to boot them. It seems that each stick has a finite lifetime before RISC OS refuses to boot it, even though it’s perfectly readable.

To save me a lot of digging, can anyone point me at a timeout in the RISC OS sources that I can increase to keep me going?

Perhaps that’s another parameter that could go in the extended “CMOS RAM” at some point, along with the battery charge settings.

Wouldn’t it be better to boot RiscOS from micro SD card? The easiest would be a large file with an image of an ADFS hard disc. This way you wouldn’t need a working RiscOS machine to create a working Beagle Board and we don’t need to partition the card.

There wouldn’t be any difference for the drivers in RiscOS, for partitions you need an offset sector, for the file also.

Wouldn’t it be better to boot RiscOS from micro SD card? The easiest would be a large file with an image of an ADFS hard disc. This way you wouldn’t need a working RiscOS machine to create a working Beagle Board and we don’t need to partition the card.

Sorry, I don’t understand. RISC OS is booted from a micro SD (BBxM) or full size SD (BB). The HardDisc[n] image is no good as read only; it has to be writable in order to be of any use to anyone. It certainly isn’t writable on the SD card.

There wouldn’t be any difference for the drivers in RiscOS

If the SD card is to be writable, someone has to create drivers for it. Currently that’s me, but not for the purpose you’re describing.

OK, I was not clear. I mend as HardDisc image, then indeed, it need to be writable.

The idea is you have one big continues file on the SD card so you don’t have to bother with the FAT, just the offset from the start of the disc. I have created code for reading/writing VFAT before so if you need a hand?

The HardDisc[n] image is no good as read only; it has to be writable in order to be of any use to anyone.

Would it? Doesn’t RISC OS have facilities for read only boot? (Like for school use.)

With the design of the Beagleboard, wouldn’t a system where !boot was read only and lived on the SD card (1), user settings, files, system extensions and apps (2) lived on USB storage and scrap was in RAM drive, work better?

1) whether it is as just suggested, on a partition or even in Resources in an enlarged ROM image.

2) experienced users could move the latter two over to the SD card, if they wished.

So where are you going to store your files, then? How useful do you think any OS is where you can’t write or store anything (without something of a rigmarole)?

So where are you going to store your files, then?

D’oh! Updated with correction :)

(Note – I am assuming that the SD card is significantly faster than USB, is that correct?)

But why divide apps out into some that live in ROM and some that live on USB? Why don’t they all live on USB like the files do? What is to be gained by dividing them?

(Note – I am assuming that the SD card is significantly faster than USB, is that correct?)

I really don’t know. If both are optimised (and neither is, today), I can’t imagine there would be much difference between them.

I’m assuming that the SD card is quicker, if not the the location of the apps is irrelevant. (In fact most of the idea depends on that)

However, one advantage of having a read only base system, is that if there is a problem, you could revert to the base system (by unplugging the USB drive and plugging a blank one in) and see if the problem still exists.

The advantage of it being read only, is the limited writes on SD.

I don’t think dividing is a good idea. ‘Just’ use it as a hard disc. 2 or 4 GB is great to create a simple RiscOS system.

I really don’t know. If both are optimised (and neither is, today), I can’t imagine there would be much difference between them.

I am thinking of it like comparison to IDE vs USB. However while that would be true and valid for CF cards, SD are different and could presumably quite easily be far slower than CF.

I don’t think dividing is a good idea. ‘Just’ use it as a hard disc. 2 or 4 GB is great to create a simple RiscOS system.

It certainly isn’t writable on the SD card.

Since the SD card can’t currently be written to from RISC OS, (I wasn’t even aware RO could read from it yet.) any hard disc image would be read-only.

Therefore user data and settings, updated modules and apps would have to be stored somewhere else.

It would move us to a similar situation to a floppy based archimedes where the main system is read only. I think this would be desirable.