PandaRo Upgrade 5.22 to 5.24

Multiple update attempts failure! No matter whether I put 5.24 or 5.25Dev ROM image in Loader, the Switcher info reports 5.22 (13-Apr-15), and all *help module dates are 2015 or earlier. My upgrade attempts were imbecilic. I copied !Boot from HardDisc4/5/24 over the existing !Boot (without using merge) along with the other HD components, though I later did use Merge. I know that at some point I ran both InSituBootUpdate and !SDCreate, but to what effect I know not.

I have various copies of the ROM image on the SSD (none at root level), and assume that the boot process is reading an old one of those. If anyone knows how I can get things back to how they should be, I would be most grateful.

It says much for the OS and all those who support it that I still have a working machine.

Presumably the PandaRo loads the rom from an SD card. What files are in !boot.loader on the SD card? If you are also using an SSD it doesn’t matter what is on that it doesn’t affect anything.

BOOT/SCR dated 2012
CMOS dated 2015
MLO dated 2011
riscos dated 17:45:08 15 Apr 2018
U-BOOT/BIN 2012
Temp (a directory I created yesterday which has a couple of renamed ROM images in)

It looks similar to my PandaBoard so it should work – especially if all you have changed is the riscos file. Are you softloading a rom? If so there would be something in SSD:$.!boot.choices.boot.predesk if you are booting from an SSD. On an Iyonix its called !!!softload or something like that – Though I don’t think a softload was available for the beagleboard but CJE may have done something different.

Is it difficult to unplug all storage devices except the SD card? If not it would be interesting to know what os booted with just the SD card attached.

I don’t think there is a softload option, certainly I have noticed nothing during Boot and there are no soft files (except M’soft).

I don’t know how to unplug storage devices, and in Configuration.Discs there is 1 CD, 1 Floppy (the SD card I assume since there is no floppy drive) & 0 SCSI, so nothing I can change there.

Does the timestamp on riscos on your PandaBoard agree with mine? (I assume it is impossible for an old ROM image to have been picked up accidently in the build).

I usually use a newer version but I’ve just downloaded 5.24 for the panda from this site, dropped the riscos file into !boot.loader on the SD card and it works fine. The riscos file is dated 15 Apr 2018 – Switcher reports 5.24 (16-Apr-18)

I’m a bit confused now as to whether you have a USB SSD drive or whether you mistyped SD.

I’ve got into the habit of always dismounting the disc after changing the rom file as in the past I’ve had problems changing roms – I change roms quite often.

Could you recover the situation if the machine didn’t start?

If you could what I would do is this. I’d:

1) copy the files from !boot.loader to a directory outside !boot.loader.
2) wipe all the files from !boot.loader.
3) put the files back in to !boot.loader in this order:
MLO
UBOOT/BIN
BOOT/SCR
riscos
CMOS

Edit: I should add use a fresh copy of riscos

I have 120G internal SSD (I presume it is USB) and an SD card of which 30G appears to be visible (I presume it is a 32g card partitioned in some fashion).

Never thought of dismounting a disc since I last used a floppy. I thought the effect of dismounting a hard drive was merely to park the read head and close the directory display until the next time the disk was accessed, so I would not expect it to have any affect across a restsrt

If the machine did not start I would be stuck without a thorough briefing beforehand. However, I have Windows and Linux on another machine so could still access the internet.

Given that the machine appears not to be booting from !boot.loader the chances of it not starting without the SSD seem high. I’ll try your suggestion and work out what to do later.

Seems I was right. Dead machine: no display, can’t see the SSD across the network. Hey ho, gives me something to think about.

There’s one way to find out for certain if it is booting from the sd card and that is to open the box remove the sd card and try starting up. If it does start up the rom is being loaded elsewhere if it doesn’t then I think the FAT partition directory is corrupted. If you decide to wipe the loader directory copy the files onto a FAT memory stick or card then you can use windows to put them back onto the riscos sd card if you need to – windows will just see the FAT partition of the riscos card.

Is there a loader directory in the SSD !boot?

I wonder if, during your upgrade process, you have actually copied the loader directory, so that as seen by the RISC OS file system, it is no longer the one that is in the FAT partition of the card. THus, while you think you are upgrading the ROM in loader, this is now in the filecore partition. When the Panda starts up it is still accessing the files in the FAT partition which have never been changed.

I think the above scenario is possible, though may, of course, be a total red herring.

Sounds resonable Chris, thanks. Can one look at the filecore partition? All I could see just now when I stuck the SD card into my ARMX6 was a FAT32 directory with the content of Loader in it.

If I use !SDCreate does it recreate the SD card from scratch with all the appropriate partitions? Or do I need to go back to CJE?

That’s normal. When you have fat32fs running you only see the fat32 partition. Check if the date of riscos is 15th Apr 2018 if not then it’s likely you have moved loader and have been changing a copy. It should still work, it’s likely only the fat part of the SD card is being used, once riscos is loaded you probably have the CMOS set to boot from the SSD

!SDCreate will wipe the disc leave the disc looking like it has a small Fat partition.

Thanks all. When looking at the riscos date on the SD card it was 2015, so I must have moved loader somehow. Don’t know where as I could not find a trace.

I have just tried to use !SDCreate and seem to have messed that up too as the result has neither an MLO nor a UBOOT file. In vain hope I stuck it back in the Panda, but that remains dead as a dodo. Just to seal things off I have a directory on the ARMX6 which purports to contain a complete backup of the Panda. Guess what – its empty!

Not going to do any more now and busy tomorrow and Monday so I will try to pick things up later in the week.

Ok so this process will lose any files already on the SD card so best use a spare one.

You may still be able to access the RISC OS files on the existing Panda SD card – rmkill fat32fs on an ArmX6 should give you access. If the procedure below works for you we may be able to transfer the loader files to your Panda SD card to get it working.

When finished there will be no RISC OS files on the SD card – you need !SystemDisc to have a RISC OS partition. This procedure allows you to load the OS from the SD card and run !Boot on a different RISC OS SCSI drive.

If using SparkFS you don’t need to unpack the zip files.

If you have an existing CMOS file use that in step 4.f

1) Download Panda 5.24 stable "OMAP4/5/24/zip":https://www.riscosopen.org/content/downloads/pandaboard
2) Download the loader files "pandaboottest/zip":http://www.riscosports.co.uk/pandaboottest.zip
3) Open OMAP4/5/24/zip and run !SDCreate

4) In sdcreate:
      a) Select 'Create Image' 
      b) Select Machine type 'PandaBoard'
      c) Drop OMAP4/5/24/zip.riscos into the 'ROM image' field.
      d) Drop pandaboottest/zip.boot.MLO into the 'x-loader/MLO' field.
      e) Drop pandaboottest/zip.boot.u-boot/img into the 'U-Boot' field.
      d) Select 'Write image'
      e) Ensure the 'SCSI drive' is the correct one.
      f) Leave 'CMOS' file empty if you don't have an existing CMOS file.
      g) Select 'Run'

5) When SDCreate is finished if you now look at the created disc:
      a) remove BOOT/SCR
      b) rename U_BOOT/BIN UBOOT/IMG
      c) add pandaboottest/zip.boot.preEnv/txt
      d) add pandaboottest/zip.boot.uenv_cmos/txt
      e) rename uenv_cmos/txt uenv/txt
      

If you didn't use your existing CMOS file Booting may stop at 

'Waiting for boot drive to be ready; press Escape to cancel'

If that is the case:

1) Press escape - this takes you to the supervisor prompt
2) At the supervisor prompt type "configure scsifsdrive 4" return.
3) reboot (ctrl - break)

It should now run !Boot on your USB SSD. If you didn’t use your existing CMOS file some settings may be changed.

Having updated from RISC OS v5.23 to v5.24, Reporter is giving a ‘red’ error as follows.

16:13:19.30 SCSI:DISMOUNT 8
Disc drive not known

This is repeated 8 times. The boot-up proceeds as normal, but I haven’t noticed this error before.
It occurs while running the BASIC program, SetChoices, in Boot.Utils and seems to occur at the line
SYS"OS_ServiceCall",0,&810C1:REM Boot resources set
near the end of the program.

Reporter also tells me that “ZeroPain is not supported by this RISC OS version” which is how I remembered it with even numbered versions of the OS; but what happens when I try to run one of those programs that tries to access Zero Page?

Reporter continues to give the error “File ‘VIDCBandwidthLimit’ not found”, presumably coming from a line in PreDesk.Configure.!Run . Is this line still needed?

Reporter also tells me that “ZeroPain is not supported by this RISC OS version” which is how I remembered it with even numbered versions of the OS;

If you’ve upgraded to the latest version of ZeroPain from the 5.25 releases, then presumably not. ZeroPain wasn’t applicable to 5.22, so there isn’t a precedent.

but what happens when I try to run one of those programs that tries to access Zero Page?

I presume that the compatibility page is active by default on 5.24? If so, they should have no problems running.

This short BASIC program should identify how things are set up on a system.

REM >TestPain

SYS "XOS_PlatformFeatures", 0 TO features%; flags%
IF ((features% AND &80000000) = 0) OR ((flags% AND 1) = 1) THEN
  PRINT "High Vectors are not supported on this system."
  END
ENDIF

SYS "OS_PlatformFeatures", 32 TO location%
IF location% = 0 THEN
  PRINT "Low Vectors are in use."
  END
ENDIF

PRINT "High Vectors are in use, at &";~location%

SYS "XOS_Memory", 20, -1 TO ,compatibility%; flags%
IF ((flags% AND 1) <> 0) OR (compatibility% = -1) THEN
  PRINT "Compatibility Page isn't supported or required on this system."
ELSE
  PRINT "Compatibility Page is ";
  IF compatibility% = 1 THEN PRINT;"enabled." ELSE PRINT;"disabled."
ENDIF
END

Reporter also tells me that “ZeroPain is not supported by this RISC OS version”

I thought there was an update of ZeroPain that stopped that.

Colin, despite the excellence of your instructions we are getting too far outside my comfort zone for me to be confident of carrying them out without my ham-fistedness getting in the way and purhaps putting my ARMX6 out of commission as well. I have decided to go back to CJE. Thanks again.

Steve F., thanks for the program. Running it tells me that Panda is running a high vector version (5.24) and compatibility page is enabled.
I still don’t know whether the “SCSI DISMOUNT 8 Disc drive not known” matters.