Towards BeagleBoard "CMOS RAM"

The bugs were less than trivial then..

So far nothing has affected the pen drive SCSI 0 (so far as I know). Using SCSI::0.$.Utilities.Mass-FS.!SCSIForm to reformat the SCSI::4 drive and copying plain vanilla HardDisc4 image onto it (from ShareFS over the network accessing $.Public on VRPC for the decompressed HardDisc4/util) and trying to recall all the ‘bug fix’ type changes that were done to get the following working:

http://www.svrsig.org/SetUp.htm Edited 2000 Fri 28th Jan

So far the vanilla SCSI 4 drive is working and I’ve worked through the other bits carefully and it’s all working again.

Many thanks.

Just one thing (of many!) I’m not sure of. Why should I need to reformat the hard drive, when it was originally formatted using SCSIForm on my Iyonix?

If you used one of the buggy ROM images to write files to the hard drive, then they could have been written to the wrong place, leading to (a) other files being overwritten, or (b) the files appearing corrupt when you try reading them back using the new ROM image.

http://www.svrsig.org/SetUp.htm

Do you intend for this to be a reasonably long term page? It’d be useful to link to from the How to get started with a BeagleBoard page. Even better would be a facility to host images (although not in the current release version) on the site for use in the wiki.

Do you intend for this to be a reasonably long term page?

Is there an online explanation how to use the new ROM? I’ve used Tank’s ROM hack and have been booting from HD4 in the past but now have to use the old pen drive boot again. Copying the boot file didn’t seem to help.

Formatted my HD4 now and installed the new Boot file from RAM but can’t get it to initialise. ESC gets me to the supervisor but where can I set my BB to actually boot from HD4?

Okay, I did the whole configure scsifs 4 thing and tried to savecmos cmos. Resulted in “the drive is empty”. Been able to save the smos to a usb stick after plugging one in. Tried to do the same with the sd card but again: “drive is empty”. Copied the cmos~1 from usb to the sd card under windows but again the BB wouldn’t boot from HD4

BB wouldn’t boot from HD4

For the drive to appear as SCSI::4 it must be connected to the OTG port. Is the drive icon visible on the icon bar? Is it set to OPT 4,2?

For the drive to appear as SCSI::4 it must be connected to the OTG port.

That’s not right. I have a USB HD connected to one of the ‘normal’ USB ports and that reports as drive 4.

@Patric If you go to the desktop, does your storage device appear on the iconbar? If not, then it’s not being recognised which is a separate issue to the CMOS working.

@Andrew

My HD4 shows up om the iconbar, no problems there. It’s connected to my powered hub, not directly to the onboard one nor the OTG port though.

The way I did it was to boot off the new ROM to the supervisor (*) prompt, then type the following: -

conf.files.scsi conf.scsifsdr.4 conf.lmt.ip dir scsi::4.$ !boot

This brings you to the desktop (usually via an error box – cancel it).

Run Configure (double-click !Boot) Set all the other parameters you want (especially 0 floppy drives) Once everything is set, click menu over the configure window and Save CMOS - saves to scsi::4.$.CMOS.

Remove the MicroSD card from the BB and insert it into a USB card reader which you then plug into a BB USB port. Copy CMOS from the boot drive to the card, dismount the card. Unplug the card reader and re-insert the mSD card into the BB. Restart the BB and it should boot straight to the desktop! :-}

The commands should have read: -

conf.files.scsi

conf.scsifsdr.4

conf.lmt.ip

dir scsi::4.$

!boot

not all one line as previously mangled!

@chris

plugged in the sd card via adapter and had a look at the “cmos_~1” file. Not sure what you mean re &D0 being 000 or 020?

Argh I think I killed my BB: no Boot at all. LCD remains as dark as the keyboard. Onboard LEDs on so not power related

I had that once, I had to remove and reinsert the SD card a couple of times, then it booted ok. Do it carefully though, don’t want to break the socket.

Do you still have the SD card which came with it? Does it boot from that?

I was talking about the original card as I had copied the new ROM to it. Managed to get the second card running though and copied the ROM to that one now. Original card not working under windows either, phew. Cheaper to replace sd for sure! Can’t say I’m too happy with the situation though

Have you downloaded Jeffrey’s ROM from the 27th?

http://www.phlamethrower.co.uk/misc2/OMAP3Dev.zip

If your ROM image is older than that, you are at serious risk of data being written to the wrong address or even the wrong drive, potentially making a device unusable.

It sounds as if this might have been what caused your SD card to die after you used RISC OS to write a CMOS file.

Followed Graham’s instructions to the letter, apart perhaps from first deleting the mSD cmos and Shift-copying the new one over. On re-start again nothing happened. Bugger me I thought, not again! Gave it another try and this time my BB booted straight into the desktop. Cheers for the help!

Have I got this right: there is no HAL function to read the RTCC? RTCCs differ between platforms (the Y2010 bug was caused by this difference), so I thought the RTCC would have been abstracted out. If it has, I can’t see the call(s).

The relevance is that, when I (re)write the CMOS file, I should update its write (and possibly creation) time(s), so I need to read the system date and time.

I guess the OS should be running when the HAL call to write the CMOS data is made – can anyone confirm this? – and if this is the case, I can call RISC OS’s functions.

There aren’t any direct HAL calls for reading the RTC. Instead, the OMAP port uses the newer HAL device framework (see here and here, and HAL.OMPA3.s.RTC for the OMAP implementation). The code in s.RTC isn’t really designed to be used from within the HAL, but it’s probably better to use it than to try calling RISC OS (especially since I’m not sure when RISC OS will first attempt to write to CMOS).

Here’s an (untested!) assembler function that should work when called from C:

; int readtimefornvram(struct rtctime *)
; Reads BCD time into given rtctime struct
; Returns zero on success, nonzero on failure
readtimefornvram
  MOV a2, a1
  ADRL a1, RTCDevice
  LDR a3, HALInitialised
  CMP a3, #0
  ADREQL a3, IIC_DoOp_Poll
  LDRNE a3, OSentries+4*OS_IICOpV
  B RTCReadTime

Note that you’ll need to export RTCDevice and RTCReadTime from s.RTC (or just stick the above function into that file). Also note that the day and month fields are 1-based (as indicated by the flags set in the RTCDevice struct)

I don’t think RISC OS will write to CMOS on its own. Isn’t it always a user action?
On the other hand, if the boot disc is not correct and the !Boot sequence isn’t run, a user can use *config commands. Don’t know is RISC OS is started enough in that state.

Writes to CMOS aren’t always the result of a user action. The OS will reset CMOS to defaults during startup if it detects that it’s corrupt. I haven’t checked exactly when it happens, but there’s a chance it will happen before the system time, or even the SWI handler, is initialised.

Another thing that can cause silent CMOS updates is when the year has changed. RISC OS likes to know the full 4-digit year, but RTCs often store only 2 or 1 digits, so a couple of bytes in CMOS are used to augment the data in the RTC. So if the year has changed then RISC OS will try updating CMOS during the system time initialisation – at which point it’s fairly safe to say that any attempt to read the system time via a SWI will fail.

The corrupt CMOS setting could be made a user action and the updating of the year doesn’t have to be at initialisation but changing that only to get a correct time/date for writing a CMOS file looks a bit too much.
On the other hand, why does the CMOS file need a valid/correct timestamp?

The corrupt CMOS setting could be made a user action and the updating of the year doesn’t have to be at initialisation

but as you say…

but changing that only to get a correct time/date for writing a CMOS file looks a bit too much.

Agreed – it’s easier to get the current date/time; it’s simply a case of how to do so. The problem is definitely soluble, and isn’t even difficult; it just requires to know how to do it. I know how to write the directory information – that’s not difficult; Jeffrey has shown me how to get the information to write (thanks, Jeffrey!)

On the other hand, why does the CMOS file need a valid/correct timestamp?

As with any file, it can be useful to see when the information dates from.

I wish I were going to the SAUG meeting tomorrow!