5.30 Stable

@Rick Murray

DiscKnight says that the disc (SD card) is good. It passed all the checks.

Internal error: undefined instruction at &20259C04

After you get that abort (or similar) can you try *where and *showregs (or Where from the Reporter menu).
They should show what module is aborting, and some clues why.

I have seen no mention about how an IP address is being obtained, DHCP or Static , so it would be good to confirm that.

Another other way to try and get things narrowed down and see if it is something specific to David’s Disc image is causing the issue, is to try a clean SDCard set up, if David has one to hand, or to rename the Choices directory in !Boot and reboot and hence get a new day1 set of core choices.

The later will hopefully highlight if anything in the setup is causing the issue and I have narrowed down things using this method before.

Of course you would need to reconfigure your network and following Rick’s instructions on loading the modules before trying Sprow’s basic script.

As ever back ups are your friend and only do it if confident you know how to get out of it.

@Martin Avison

I got the following.

*showregs
Register dump (stored at &20052210) is:
R0 = 00000000 R1 = 20528948 R2 = 2052887C R3 = 205281BC
R4 = 00000000 R5 = 002CB940 R6 = 212D6C0D R7 = 00000523
R8 = 20D0B594 R9 = 00000126 R10 = FA20021C R11 = FA207ECC
R12 = 002CB940 R13 = FA207EB4 R14 = 20245414 R15 = 20259C08
Mode SVC32 flags set: nZcvqjggggeAift PSR = 40000113
*where
Address &20259C08 is at offset &00016F94 in module ‘SharedCLibrary’

End

The SharedCLibrary is version 6.22 (29 Nov 2023).

[added] Verma says that SharedCLibrary is Loaded.

Verma says that SharedCLibrary is Loaded.

That means the SharedCLibrary is softloaded which should not be the case with an OS5.30 ROM.

Address &20259C08 is at offset &00016F94 in module ‘SharedCLibrary’

That seems to indicate that the Clib being used was not in ROM, but was softloaded.
It that a clue? The 5.28 ROM is still being used!
Probably also need the code around the abort, to identify what actually happened. *Memoryi will do it (cannot remember the exact syntax, sorry)

The 5.28 ROM is still being used!

Rereading the thread that might be the case. However with OS5.28 plus softloaded SharedCLibrary 6.22 HTTP_Client does complete on the Titanium.

Address &20259C08 is at offset &00016F94 in module ‘SharedCLibrary’
bq. However with OS5.28 plus softloaded SharedCLibrary 6.22 HTTP_Client does complete on the Titanium.

Could it be that there is more than one softload going on and that is causing issues or is it this issue raised on another thread?

The version in !System contains the SWP instruction and seems to be a much smaller file. The SWP instruction does not work on Pi 3 and 4 models, maybe others. Not without my ACE module (ARM Chip Emulator).

Update: One thing to do is to actually update to 5.30, including firmware changes, and see if the issue goes away. I would backup the 5.28 ROM in Loader first as well.

@Martin
I found this:
*help MemoryI
==> Help on keyword MemoryI
*MemoryI disassembles ARM or Thumb instructions.
Syntax: *MemoryI [P] [T] <addr1|reg1> [|-] <addr2|reg2> [ <addr3|reg3>]]
*
The minimum I could enter for the command to be meaningful would be (addr1 or reg1) and (addr2 or reg2); but I know not what addresses or registers to enter.

@Doug
Verma says that there is SharedCLibrary v6.08 Dormant in the ROM and SharedCLibrary v6.22 Loaded in RMA (in !System.500.Modules).
Way back I thought of just going ahead with the ROM upgrade to v5.30 in the hope that this would rectify the apparent incompatibility between the InSituBootUpdate and OS5.28. It’s looking as if my thought is correct.

This thread has a lot of views, and so I wonder whether others are running into the same problem on R Pi 3 and 4?

In the softloaded Clib v6.22 (29 Nov 2023) in !System.500.Modules, at +&16F90 there is a SWP instruction!
So it seems to confirm Doug is correct, and it is the same problem as in thread

Address &20259C08 is at offset &00016F94 in module ‘SharedCLibrary’

That seems to indicate that the Clib being used was not in ROM, but was softloaded. It that a clue?

Yes, that does seem to be key here. Offset +16F90 in the softloading CLib is a SWP instruction, and the abort is reported at +16F94 due to PC pipeline type stuff.

However with OS5.28 plus softloaded SharedCLibrary 6.22 HTTP_Client does complete on the Titanium.

That’ll be because the Cortex-A15 supports SWP (well, unless you go out of your way to actively disable it via the appropriate coprocessor register).

*Memoryi will do it (cannot remember the exact syntax, sorry)

*MemoryI PC -40 +80
will give a bit either side of where the program counter faulted at. However in this case *Where has given us enough to go on with the offset – just look in the module in StrongEd at +16F94.

So we can probably conclude:

• that David L is mid-upgrade on something where SWP isn’t supported
• the RMEnsure in !System.!Run is forcing a newer CLib to be loaded off disc because the ROM isn’t yet updated
• the copy on disc tries to do a SWP and so aborts

The quickest escape is to do as Doug suggests and update the ROM to something with CLib 6.19 or later in (anything would do 5.29, 5.30, 5.31) to stop one being loaded off disc or for a temporary bodge comment out the RMEnsure in !System.!Run. The reason the RMEnsure got bumped up was because that’s the first version which will check that a program gets safely linked with the matching stubs.

Sounds like the use case of trying to apply only the disc update on a processor which doesn’t support SWP didn’t get exercised by any of the 4 release candidates between December 2022 and August 2023.

Memoryi

What you need is
*memoryi <abortaddr> -20 +40
where is the address the abort was reported at (eg 2059204)
This will display the 8 instructions before and after the abort, but I suspect a SWP is centre stage!
edit: Sprow just beat me to it!

I have just tried running Sprow’s program on my Pi4B here, which has been updated to 5.30 Insitu and ROM, and (after loading the 3 modules) it ran without problem. It was using Clib v6.22 (29 Nov 2023), but from ROM.

It is certainly worth trying the 5.30 ROM – just rename the unused previous one to try it.

If it is just an unguarded SWP in the Disc SharedCLibrary then it may sufficient simply to softload 6.22 over the ROM 6.22 to show the fault, but it is not. It is not quite that easy.

For the RPi4B an OS5.28 ROM s not immediately to hand but an early 5.29 is. The Boot is my current 5.31 version, InSituBootUpdate had been run when OS5.30 arrived.

With that 5.29 ROM on the SD card, and after those later incompatible Choices were X’d out the way, the boot completed but with this error. Without further digging it is not known what caused the fault during the boot process. The same error also occurs with HTTP_Client.

(A bit later. It was vncserver that error’d in the boot.)

11 May 06:45:46 000 80000000: Error from (unknown): Internal error: undefined instruction at &20318484

*where
Address &20318488 is at offset &00016F94 in module 'SharedCLibrary'

*help sharedclibrary
==> Help on keyword SharedCLibrary
Module is: C Library       6.22 (29 Nov 2023)

Verma
   Dormant    SharedCLibrary     6.08
   Loaded     SharedCLibrary     6.22 (29 Nov 2023)    Y

*FX0
RISC OS 5.29 (15 Nov 2020)

*memoryI PC -40 +80
20318448 : .... : 0A00000C : BEQ     &20318480
2031844C : . †„ : E3A02000 : MOV     R2,#0
20318450 : ...Í : EA000001 : B       &2031845C
20318454 : ..†„ : E3A00006 : MOV     R0,#6
20318458 : 3..Ô : EF020033 : SWI     XOS_UpCall
2031845C : ü.ë· : E1910F9F : LDREX   R0,[R1]            ; ARMv6 or later
20318460 : í?Å· : E1813F92 : STREX   R3,R2,[R1]         ; ARMv6 or later
20318464 : ..3„ : E3330001 : TEQ     R3,#1
20318468 : ˚ˇˇ. : 0AFFFFFB : BEQ     &2031845C
2031846C : ..0„ : E3300000 : TEQ     R0,#0
20318470 : ˜ˇˇ. : 0AFFFFF7 : BEQ     &20318454
20318474 : .ù‰ : E49DF004 : LDR     PC,[R13],#4
20318478 : ..†„ : E3A00006 : MOV     R0,#6
2031847C : 3..Ô : EF020033 : SWI     XOS_UpCall
20318480 : ..†„ : E3A00000 : MOV     R0,#0
20318484 : ê..· : E1010090 : SWP     R0,R0,[R1]
20318488 < ..0„ : E3300000 : TEQ     R0,#0
2031848C : ˘ˇˇ. : 0AFFFFF9 : BEQ     &20318478
20318490 : .ù‰ : E49DF004 : LDR     PC,[R13],#4
20318494 : ..†„ : E3A00006 : MOV     R0,#6
20318498 : 3..Ô : EF020033 : SWI     XOS_UpCall
2031849C : ..P· : E1500000 : CMP     R0,R0
203184A0 : .†· : E1A0F00E : MOV     PC,R14
203184A4 : . †„ : E3A02000 : MOV     R2,#0
203184A8 : °¡p‡ : E070C1A1 : RSBS    R12,R0,R1,LSR #3
203184AC :  ..: : 3A000020 : BCC     &20318534
203184B0 : !ƒp‡ : E070C421 : RSBS    R12,R0,R1,LSR #8
203184B4 : ...: : 3A00000F : BCC     &203184F8
203184B8 : ..†· : E1A00400 : MOV     R0,R0,LSL #8
203184BC : ˇ$Ç„ : E38224FF : ORR     R2,R2,#&FF000000
203184C0 : !¬p‡ : E070C221 : RSBS    R12,R0,R1,LSR #4
203184C4 : ...: : 3A000017 : BCC     &20318528
*

With that 5.29 ROM on the SD card […] the boot completed but with this error.

What’s mildly perplexing is why the SWP is ever reached. The O__swp_available flags are tested first on entry to AcquireMutex then it’s actively chosen to take the SWP path rather than the LDR/STREX path. What does

SYS"OS_PlatformFeatures",0 TO ff
PRINT ((ff>>11)AND7)EOR1

show? I’d expect 6 on something that doesn’t have SWP.

I’d expect 6 on something that doesn’t have SWP.

6 it is.

fx0
RISC OS 5.29 (15 Nov 2020)
*
*sprow
         6

REM djp
REM PRINT "PlatformFeatures"
  SYS "OS_PlatformFeatures",0 TO pf%
  IF pf% AND (1 << 11) THEN
    PRINT "SWP not available"
  ELSE
    PRINT "SWP available"
  ENDIF

*djp
SWP not available
*

Pity ‘Ace’ with Swp couldn’t be added to the Rom for the machines without SWP arm code.

Sounds like the use case of trying to apply only the disc update on a processor which doesn’t support SWP didn’t get exercised by any of the 4 release candidates between December 2022 and August 2023

Normally I follow the path of Disc update then ROM on the systems I have and unfortunately on the system type this issue may be seen on, Pi3/P4b, I also actively test out the beta ROM’s so I would have had a 5.29 ROM version on them.

I did do a 5.28 standard build test update on a backup card I have but that normally resides in either an old Pi1 or Pi2.

My test systems normally are Iyonix/P1B-4B/Pi400, Pandaboard & Beagleboard and even on the Iyonix I don’t alays test now days and hence why the Iyonix softload issue wasn’t reported until recently.

These same systems have also been used for beta testing the ROD stuff and thus again that limits what I test and when.

Just shows the more people that test helps find these edge cases and with a good back up system you can always go back if an issue arises.

Anyway glad I don’t seem to have thrown a red herring on this again :-)

My Pi4 has been upgraded to RO5.30 InSitu & ROM, but I reverted to using the 5.28 ROM.
During boot there was an abort – at +&16F94 in Clib.
The ROM has Clib 6.08, but !System.!Run has a line
If Boot$OSVersion >= 310 Then RMEnsure SharedCLibrary 6.19 RMLoad System:Modules.CLib
Which softloads 6.22.
The abort was provoked by vncserv_config (like DavidP), which was presumably the first thing to excercise that part of clib.

I can confirm that the PlatformFeatures snippet returns 6. (Titanium gives 7)

What’s mildly perplexing is why the SWP is ever reached.

I think that is a Sprow understatement!

If it is just an unguarded SWP in the Disc SharedCLibrary then it may sufficient simply to softload 6.22 over the ROM 6.22 to show the fault, but it is not. It is not quite that easy.

It’s my turn for the red herring!!

Revisiting this it is possible to reproduce the fault with HTTP_Client and vncserver on OS5.31 after soft loading the Disc CLib 6.22.

My apologies.

You can recreate the bug on a standard install of RO 5.30 although you should know that you will need to restart your machine after trying this. First, load in clib with *RmLoad System:Modules.clib and then go to Configure, select boot, run and then click set. You should get an error – if your machine does not have the SWP instruction. There is probably no error on a Pi 1 but there is on Pi 3 or 4.

The version in the ROM is 6.22 and the version in system is also 6.22, both with the same date yet they are not the same. The ROM version does not have the SWP instruction so works as intended but the !System version does have it and causes issues on some machines.

I have built a Pi specific standalone CLIb 6.22 module by setting Machine to RPi in Env in Builder, and that, obviously, does not have any SWPs and does not fall into the hole that the conventional Machine All CLib version does. Interesting as this is it does not help much.

The CLib in !System is different from ROM versions because !Boot is universal and ROMs are not.

I have taken the plunge and upgraded the ROM and boot loader files to 5.30. No problems so far, except that HTTP_Client did not return a web page, but the following.

*SDFS::PiAno.$.HTTP_Client
Got session handle 547942708
DNS record for www.howsmyssl.com is 34.71.45.200
Connected to host on port 443
Requesting page /a/check…………….
Received 1187 from the host (max 4096)
-—————————————————————————————————————-
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Content-Length: 3437
Content-Type: application/json
Strict-Transport-Security: max-age=631138519; includeSubdomains; preload
Vary: Accept-Encoding
Date: Sat, 11 May 2024 11:32:12 GMT

{"given_cipher_suites":[“TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256”,
“TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256”,
“TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256”,
“TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384”,
“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”,“TLS_DHE_RSA_WITH_AES_256_GCM_SHA384”,
“TLS_ECDHE_ECDSA_WITH_AES_256_CCM”,“TLS_DHE_RSA_WITH_AES_256_CCM”,
“TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384”,
“TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384”,“TLS_DHE_RSA_WITH_AES_256_CBC_SHA256”,
“TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA”,“TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA”,
“TLS_DHE_RSA_WITH_AES_256_CBC_SHA”,“TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8”,
“TLS_DHE_RSA_WITH_AES_256_CCM_8”,“TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384”,
“TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384”,
“TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256”,“TLS_DHE_RSA_WITH_CAMELLIA_25
-—————————————————————————————————————-
Received 2374 from the host (max 4096)
-—————————————————————————————————————-
6_CBC_SHA”,“TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256”,
“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”,“TLS_DHE_RSA_WITH_AES_128_GCM_SHA256”,
“TLS_ECDHE_ECDSA_WITH_AES_128_CCM”,“TLS_DHE_RSA_WITH_AES_128_CCM”,
“TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256”,
“TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256”,“TLS_DHE_RSA_WITH_AES_128_CBC_SHA256”,
“TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA”,“TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA”,
“TLS_DHE_RSA_WITH_AES_128_CBC_SHA”,“TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8”,
“TLS_DHE_RSA_WITH_AES_128_CCM_8”,“TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256”,
“TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256”,
“TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256”,
“TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA”,“TLS_RSA_WITH_AES_256_GCM_SHA384”,
“TLS_RSA_WITH_AES_256_CCM”,“TLS_RSA_WITH_AES_256_CBC_SHA256”,
“TLS_RSA_WITH_AES_256_CBC_SHA”,“TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384”,
“TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384”,“TLS_ECDH_RSA_WITH_AES_256_CBC_SHA”,
“TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384”,
“TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384”,“TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA”,
“TLS_RSA_WITH_AES_256_CCM_8”,“TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256”,“TLS_RSA_WITH_CAMELLIA_256_CBC_SHA”,
“TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384”,
“TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384”,
“TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384”,“TLS_RSA_WITH_AES_128_GCM_SHA256”,
“TLS_RSA_WITH_AES_128_CCM”,“TLS_RSA_WITH_AES_128_CBC_SHA256”,
“TLS_RSA_WITH_AES_128_CBC_SHA”,“TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256”,
“TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256”,“TLS_ECDH_RSA_WITH_AES_128_CBC_SHA”,
“TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256”,
“TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256”,“TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA”,
“TLS_RSA_WITH_AES_128_CCM_8”,“TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256”,“TLS_RSA_WITH_CAMELLIA_128_CBC_SHA”,
“TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256”,
“TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256”,
“TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256”,
“TLS_EMPTY_RENEGOTIATION_INFO_SCSV”],ephemeral_keys_supported,
session_ticket_supported,tls_compression_supported,
unknown_cipher_suite_supported,beast_vuln,able_t
-—————————————————————————————————————-
Received 115 from the host (max 4096)
-—————————————————————————————————————-
o_detect_n_minus_one_splitting,“insecure_cipher_suites”:{},“tls_version”:“TLS 1.2”,“rating”:“Probably Okay”}
-—————————————————————————————————————-

Reached EOF
Finished with handle 547942708
*

Does that help?!!

Oh, for some reason 2 bits are missing after the 2 "supported"s near the end: “:true,” and “:false,”, respectively.

Does that help?!!

Yes – that is exactly what the test program should display.

Has it also resolved the initial Hermes crashes you reported?

First, load in clib with *RmLoad System:Modules.clib

This is why one should always RMEnsure prior to RMLoad. I mean, think what happens if the ROM is 6.23 but somehow 6.22 is getting loaded in over top of it.
[which leads to the obvious question of what is blindly loading the System version of the library on the machine that is experiencing this problem?]

This doesn’t excuse the obvious problem that CLib shouldn’t be using SWP on a machine when SWP is not available.