Raspberry-Pi boots up without Loader in !Boot

I thought I had correctly updated the OS of a Rsapberry-Pi B+ ; but when I rebooted, shock horror, there was no Loader (the DOS disc) in PlingBoot!
How is this possible?

How did you update it? From within RISC OS or on another OS? There are two steps to this – the image file Loader inside !Boot has two ways into it: from within RISC OS via DOSFS and the image file Loader and from the FAT partition that overlaps with the Filecore partition to exactly match where RISC OS has placed Loader. If you update the FAT partition (e.g. on Windows) then the Pi will see that on start up. However if you delete the image file Loader from within RISC OS then that area becomes free to be used by RISC OS so its contents (i.e. the FAT partition) will soon be corrupted…

I think !SystemDisc will restore things for you.

No, I didn’t use another OS to update. Before updating, I hid, or thought I had hidden, the existing Loader DOS disc in in a sub-sub-directory of the root directory. Then updated plingBoot not realising that I hadn’t ensured that there was a (new) Loader DOSdisc in plingBoot. I guess that the hardware must find Loader DOSdisc wherever it is? If I had ensured there was a (new) Loader DOSdisc in plingBoot, I wonder what would have happened?
I was trying to update to your recent ‘8H’ firmware, but encountered some problems, like most of my choices files being deleted.

You cannot move or copy the image file ‘Loader’ without destroying its careful positioning to (i) occupy fully the FAT partition preventing FileCore from altering anything there when you create a new file and directory entry in RISC OS and (ii) making sure that the files that RISC OS sees inside the image file are exactly what the Pi sees in the FAT partition on the SD card when it starts up.

If you simply copy the !Boot directory inside Update8H over your existing !Boot, it will update just the firmware, rom, the screen configure plug-in and the zeropain module. Nothing else. Your choices should remain unaffected although any CMOS settings will be lost. Inside !Boot in Update8H is a directory called Loader containing the firmware and ROM that (provided that DOSFS has been ‘seen’) will treat the image file ‘Loader’ as a directory. If DOSFS has not been ‘seen’ then the copy operation will simply terminate with an error, exactly as if you tried to copy a directory onto a file with the same name.

If you have deleted or moved the image file ‘Loader’ so that it is no longer at $.!Boot.Loader then the update will not work.

Loader is now back in plingBoot. SystemDisc says that the SD card is a valid disc or something like that. Everything sems to work except I get some unusual screens before reaching the desktop; and, if I click on “restart” after clicking on shutdown, I get an error box (with green cogwheel) saying “memory cannot be moved”.
Is Systemdisc lying?

if I click on “restart” after clicking on shutdown, I get an error box (with green cogwheel) saying “memory cannot be moved”.

Do you have a real-time clock fitted?

Yay. It’s that error.

Yes, there is a real-time clock, but I have not had this error before, so why now?

@Chris Hall
Since my last post above, I deleted Loader DOSdisc, ran SystemDisc which said something like “You have deleted Loader, but may not have completely deleted it” and offered to completely delete it. So I accepted and put back in your firmware files of upgrade6L. It still boots up in an odd way with a low resolution display that I can’t change. Again, a ‘restart’, not a switch off/power on, gives the same error, “memory cannot be moved”.
In redoing the firmware, I did not delete any of the ‘HardDisc4’ files or directories (outside of Loader).

I would now recommend trying upgrade 8H (which implements EDID, Serial, GPIO and a 6-Mar-2017 ROM) and see if that cures the ‘memory cannot be moved’ problem. That should also sort out booting if you *Configure MonitorType EDID and *Configure WimpMode Auto after upgrading to 8H. Then you will find the updated screen configure plug-in will have your monitor listed immediately below ‘Auto’ as a selection.

…but when I rebooted, shock horror, there was no Loader (the DOS disc) in PlingBoot!

Have a comparable “problem”. I update my card in WIN. After this my Pi boot without problems but no files in the Loader folder visible. At “the end of the day” I delete.
Have try to mount the FAT partition via FAT32FS. Is aviable and all files inside…

Have a comparable “problem”. I update my card in WIN. After this my Pi boot without problems but no files in the Loader folder visible. At “the end of the day” I delete. Have try to mount the FAT partition via FAT32FS. Is aviable and all files inside…

I know others had that problem too (mainly in the days of the IYONIX and plain old FAT16 DOSFS) – Windows recognizes some structure in a different place on the medium has the central directory and uses that, while RISC OS uses another place.

I think the usual solution was to do a full format (which is not possible on Windows IIRC, but needs some Linux tool).

That “Memory cannot be moved” error on reboot seems to be triggered / suppressed by RTC and ??? It’s something that manifests on the RPi series.

I would now recommend trying upgrade 8H (which implements EDID, Serial, GPIO and a 6-Mar-2017 ROM) and see if that cures the ‘memory cannot be moved’ problem.

I would really like to understand what is going wrong. I have never seen the “Memory cannot be moved” error before. The other problem is with the screen resolution.

In the PreDesk.Configure.Monitor file there is the line
LoadModeFile BootResources:Configure.Monitors.AKF60

with no “Acorn.” between Monitors and AKF60. On another Raspberry-Pi (R-Pi_2) this causes no problems and the loaded resolution is in fact a RasPi-Builtin one; but, on my Raspberrry-Pi B+, I get a default resolution that can’t be changed as if plingBoot hadn’t been run, although it has. If on the Raspberrry-Pi B+, I insert the “Acorn.” into the full file name then it boots up with AKF60 resolutions which I can change. However, I would prefer one of the RasPi-Builtin resolutions.
How do I get the RasPi-Builtin resolutions?

Another thing I have noticed is that the screen of text before going into plingBoot doesn’t include the (white) Raspberry that I get on the R-Pi_2.

I would really like to understand what is going wrong. I have never seen the “Memory cannot be moved” error before.

Lots of people would like to get to the bottom of this one, there’s threads related to it going back to October 2015. Maybe if you go back through the commit logs and look at/understand the RISC OS sources you’ll find the bug that was introduced.

I have discovered a bit more. I have a Raspberry-Pi 2 which is working fine and a Raspberry-Pi B+ which isn’t (see the above posts). Both computers have an RTC. I swapped the micro SD cards in the two computers rather expecting the errors in the R-Pi B+ to now appear in the R-Pi 2. Well, the problems with the resolution and the odd bootup did appear now on the R-Pi2 and not the R-Pi B+; but the error after “Restart”, “Memory cannot be moved”, was stll with the R-Pi B+, not the R-Pi 2.
The only other difference is that although both cards are running RISC OS V5.23 (low vector) the one on the R-Pi B+ card is dated 13/2/17 while on the R-Pi 2 card the date is 26/10/16. The former has firmware “Upgrade 6L” and the latter has “Upgrade 5L”, both by Chris Hall.

Taking out the RTC from my R-Pi B+ solved the “Memory cannot be moved” after “Restart” problem.

An upgrade to Chris Hall’s Upgrade8H has not solved any of the monitor settings problems, in fact one is worse: A black border to the screen reducing the used area by about 10%.

I thought EDID was supposed to sort out the screen automatically.

I should add that the monitor being used is an Iiyama ProLite B2409HDS.

Taking out the RTC from my R-Pi B+ solved the “Memory cannot be moved” after “Restart” problem.

Hmm, I wonder what is going on to create this error… Could something be trying to claim workspace to update the RTC and failing? The only candidate that comes to mind here is NetTime – don’t think anything else much (other than the kernel) interacts with the clock…?

Did you try this from another thread. When I updated to the edid rom CMOS also worked differently from the version I was using. As a result CMOS wasn’t saved and I’d get what looked like a 800 × 600 screen with part of the desktop half way up the screen. The post linked above fixed things for me

Hmm, I wonder what is going on to create this error… Could something be trying to claim workspace to update the RTC and failing?

Reference to that error in Wimp.s.Wimp08 OS_ChangeDynamicArea, so RTC module and NetTime fiddling with memory allocation seem a good bet. Wonder what happens if the RTC module is unplugged? Apart from no time adjust.

Wonder what happens if the RTC module is unplugged?

To somebody suffering the Memory cannot be moved error, can you please try a reset after RMKill RTC

If that doesn’t work, try reset after RMKill NetTime.

If that doesn’t work, kill ’em both.

This may give clues as to where to look.

@Colin
Thanks for the reference to another thread; but I already had the correct lines in CONFIG/TXT and the CMOS file in Loader which responds to SaveCMOS. Monitor settings are being saved and retained after reboot.

However, there is no evidence that EDID is working. In the menu of resolutions in the Configure application there is now supposed to be one called native, but it doesn’t appear for me. I still don’t know how to get the Raspberry-Pi “Builtin” resolutions. If EDID is a module, it doesn’t appear in the list of modules given by Verma.

I have changed monitor to the Motorola Lapdock one and don’t now get the black border although still using the same Iiyama MDF.

EDID is not a module so will not appear in a listing.

To check it is nothing in your boot.choices directory causing an issue you could move the choices directory elsewhere and start from scratch.

Also isn’t the monitor you mentioned DVI/VGA only with no HDMI port. I realise DVI is virtually the same but could this be an issue as some monitors either don’t give EDID information or give incorrect EDID.

I have a PandaES and Iyonix running the latest ROM/HardDisc image to a LG M2380 and both show up the monitor in the screen configure plug in, just below AUTO, and also the native option in the resolution settings. The only thing I had with the Iyonix is that I had to manually set the screen information to my old monitor MDF first as the softload caused an issue on first reboot which stopped a lot of the boot sequence completing.

It’s the screenmodes module do a

*help screenmodes

It may be your monitor is it old? If it is a config issue

*readEDID

should set up the monitor with the EDID modes. If that doesn’t work does

savemodefile ram:$.modefile

list screen modes in the saved file?

To somebody suffering the Memory cannot be moved error, can you please try a reset after RMKill RTC

Did that – now restarts just fine.

If that doesn’t work, try reset after RMKill NetTime.

I also tried just this … and that restarted just fine as well!

Confusing progress?!

Confusing progress?!

Sort of I suppose, because you now have an element of proof that something the RTC module is doing is triggering the fault.
Since you didn’t say whether you had re-enabled RTC before doing the Kill on NetTime that could also be the trigger if called from RTC.

Back to the error message trail.
Interestingly, there are TWO wimp08 files in the source wimp08 and wimp08s.
The older wimp08 contains this comment:

; servicememory         accept/refuse to allow memory to be moved 

and at the top:

; * WARNING *

;

; This file contains old code, which is retained only for compiling Wimps to

; run on old kernels (before RO 3.70). The code contains some known bugs

; (eg. Wimp_TransferBlock).

;

; s.Wimp08s contains the current code, which is much more efficient and

; cleaner for task memory management. This works with all ARMs supported by

; the current kernel. It is not just for StrongARM, despite previous comments

; made here.