Raspberry Pi 4

Anyone else having issues with SparkFS on the Pi 4? I keep getting “Not enough free memory” errors – then “application may have gone wrong…” and Describe leads me to “Internal error: abort on data transfer at &FC17F7E4.”

*where then says it is at offset &0000CBEC in module “SharedCLibrary”

SharedCLibrary is version 6.03 (27 Jul 2019).

Bizarrely, I have occasionally spotted SparkFS on the iconbar!

This is all with a 4GB Pi 4

Bizarrely, I have occasionally spotted SparkFS on the iconbar!

Bear in mind that what you see on the iconbar is the frontend/shell and that the various compression/decompression services are done by the modules housed in !SparkFS.Modules.
A quick count in that sub-directory shows 10 modules. Any one of those could be the culprit and leave the front-end unaffected.

As to the specific error – rather reminds me of certain applications written for the 26 bit OS that had a paddy when presented with the memory map of the 32 addressing version.
Now the hardware is presenting even more memory and the OS has perhaps been amended to allow access to that larger map with a similar effect to the old 26 —> 32 change?

I’ve just tried SparkFS v1.45 on my 4GB Pi here and it runs no problem.

Using RISC OS 5.27 (01-Feb-2020) with the latest Beta HardDisc4 download.

Neither Andy nor Rob clarify what they were trying on SparkFS. Reading existing zips? Writing to existing zip? Creating a new zip? Or another compression type? Is it safe to assume both are uing v1.45 full version (Read/Write)?

I’m using the full version of SparkFS, I’ve created new zip files and decompressed existing ones.

I have found one problem on the 4GB Pi4 when trying to build a RISC OS ROM, when I select the environment in !Builder, I get an error message that says ‘unable to allocate logical address space’ Screenshot

Currently Using;
Raspberry Pi4 4GB
RISC OS 5.27 (05-Mar-2020)
DDE29a
BCM2835Dev Source (05-Mar-2020)

If I try the same ROM build on an ARMBook or Pi2, the build works as expected.

I was able to build a rom on the Pi4 with no problems (actually I did this at the SW show).

I was able to build a rom on the Pi4 with no problems (actually I did this at the SW show).

Chris, was this on a 4GB Pi or a smaller model? Also would this have been with DDE28?

4GB and DDE27

I’ve tried DDE28 and got the same issue, I’ve also ruled out ZeroPain.
Next up is a clean !Boot (Although this was taken from yesterdays Beta harddisc image)

I think the new layout of the source required !Builder to have the registered build one level further down than before. Try that.

I think the new layout of the source required !Builder to have the registered build one level further down than before. Try that.

Thanks Chris, I did twig this and I’m using the BCM2385.RiscOS as the build directory.

I’ve seen a few quirks all around memory over the last few days;
1. ‘Unable to allocate logical address space’ Error from !Builder
2. Only 2GB of RAM is being reported to BASIC Programs. (Might be by design?)
3. !StrongEd randomly reports ‘Not Enough Memory’ when editing files, just deleting two characters in an Obey file causes this

Testing on a 4GB IGEPv5 (since I don’t have a USB solution for my Pi 4 yet), I’ve been able to reproduce the “Not enough free memory” error from SparkFS. However I’m yet to see any problems with !Builder or StrongEd.

Only 2GB of RAM is being reported to BASIC Programs. (Might be by design?)

Yes, there are a few calls that clamp the returned value to (just under) 2GB, to try and avoid any integer overflow problems. I think the complete list is:

• OS_ReadDynamicArea → use OS_DynamicArea 24 instead
• OS_DynamicArea 2 → use OS_DynamicArea 24 instead
• OS_DynamicArea 5 → use OS_DynamicArea 27 instead
• OS_SetEnv (not documented in the RISC OS 3 PRMs, but it returns the amount of RAM in R2)
• Wimp_SlotSize → use Wimp_Extend 15 instead

Cheers Jeffrey, that explains the issue I had with BASIC programs.
I’ve made a fresh SD card for the Pi4 using the Stable 5.24 harddisc image, this has fixed the issue I had with !Builder.

StrongED still has issues with Obey files, I’ll ask on the StrongED mailing list about this one.

As a compatibility check I tried an RPi4 card, with the RPi4 ROM, in the RPi1 and it was fine.

As a compatibility check I tried an RPi4 card, with the RPi4 ROM, in the RPi1 and it was fine.

An extract from the config.txt provided in Update 12 explains what is going on:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0x508000
kernel=RISCOS.IMG
hdmi_force_hotplug=1
[pi4]
enable_gic=1
kernel=RISCOS4.IMG
[all]

The Pi 4 loads START4.ELF directly (it does not use BOOTCODE.BIN which loads START.ELF) and the last two lines in config.txt are only executed on the Pi 4 so the two roms are quite different and reside in separate files.

[pi4]
enable_gic=1
kernel=RISCOS4.IMG
[all]

The whole point of my test was that the RPi4 ROM is safe to run on the RPi1. During the ‘Work in Progress’ phase RPi4 requirements were added to a separate version of the HAL, so that if there was an error then that would not mess up the main stream Pi Dev ROM.

gpu_mem=128
hdmi_drive=2
hdmi_blanking=1
disable_overscan=1
fake_vsync_isr=1
# gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG
framebuffer_swap=0
ramfsfile=CMOS
ramfsaddr=0x508000
#dispmanx_offline=1

[pi4]
enable_gic=1

it does not use BOOTCODE.BIN

The RPi4 does not use that file, the functionality is now in eeprom.

*VCGenCmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110

*VCGenCmd bootloader_config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
FREEZE_VERSION=0

At some point a tool to update that from within RISC OS would be handy, to save the bother of having to it with Raspbian.

In a time soon to come there be only the one Pi ROM.

ROOL have now merged the RPi4 HAL into the main BCM2835Dev source enabling the one ROM to run on all Pi’s. That has been built from git and it does run on both the RPi3B+ and RPi4. A build should appear soon.

RPi4 USB and Ethernet modules, XHCIDriver and EtherGENET, have been added to the source but are not yet built into the ROM.

Locally merging XHCIDriver and EtherGENET builds a ROM including those modules also runs on both the RPi3B+ and RPi4. Unused modules that are inappropriate to the platform or on not yet ready for use are made Dormant.

Does this mean that even the faint of heart and impecunious will soon want an RPi4? How hassly is the hardware set up?

How hassly is the hardware set up?

I’ll have a wiki page online tomorrow morning (just waiting for the ROM to appear on the Downloads page) but in brief:

• Plug a USB hub into the USB-C (power delivery) port. This is necessary because the USB ports are currently non-functional under RISC OS.
• If your USB hub doesn’t support Power Delivery, you’ll have to power the Pi via the GPIO pins.
• The Ethernet port doesn’t work under RISC OS, so you’ll need a USB-to-Ethernet adapter or the WiFi HAT for networking.

This is still “proof of concept” and isn’t really suitable for a beginner just yet.

How hassly is the hardware set up?

Once the RPi4 has its USB and Ethernet going the RPi4, plus its power supply, will be a drop in replacement for an earlier Pi, and very nice it will be too. As it is right now extra bits might have to be bought such as a WiFi HAT, a powered hub or something to provide power via GPIO.

Once the ROM is available for download RPi4 users will no longer have to build it for themselves.

Once the ROM is available for download RPi4 users will no longer have to build it for themselves.

or download it from here

and isn’t really suitable for a beginner just yet

8~) A beginner I really ain’t – but faint of heart? Definitely. Impecunious? That too. With clear instructions, I’ll be fine if it’s going to work when I follow them. Without clear instructions, I’d probably manage but would definitely prefer to wait…

I’d rather make the instructions a little bit daunting at present. My approach is to have a working RISC OS set up as the first step, obviously not on a Pi4. Then follow the simple instruction ‘copy !Boot in the archive over !Boot on your machine using RISC OS’. Keep a backup so you can restore. Power off and on and it should just work. Now the card will work equally well on a Pi4. If it doesn’t just work you’ll have to do a restore of the files in the FAT partition on a non-RISC OS machine.

How hassly is the hardware set up?

There’s this