Raspberry Pi 4

My 8GB Pi arrived yesterday, so I’ve been able to test the HAL changes that were needed to enable use of the extra memory. Amazingly, it worked first time (although I haven’t tried stressing the system much).

Brave souls will want this updated kernel, this updated HAL, and to enable the LongDesc option in Kernel.hdr.Options.

enable the LongDesc option in Kernel.hdr.Options

How do I do that, I can’t see any such option in that file?

https://gitlab.riscosopen.org/jlee/Kernel/-/blob/LongDesc/hdr/Options#L185

https://gitlab.riscosopen.org/jlee/Kernel/-/blob/LongDesc/hdr/Options#L185

Thanks for that.

For my next failure.

Starting phase install_rom ...

HAL_BCM2835 (Sources.HAL.HAL_BCM2835)...
amu -E  install_rom INSTDIR=ADFS::ROOL.$.ROOL.RPi4.BCM2835.RiscOS.Install.ROOL.BCM2835.RISC_OS COMPONENT=HAL_BCM2835 TARGET=BCM2835
link -o aof.BCM2835 -aof o.Top o.CLib o.CMOS o.Debug o.Interrupts o.SDIO o.Timers o.UART o.USB o.Video o.DMA o.Messaging o.GPIO o.VCHIQ o.IIC o.RTC o.SPI o.Touch o.KbdScan o.DBell o.IntVC6 o.PCI o.EtherNIC  RISCOSLIB:o.romcstubs
ARM Linker: (Fatal) Input file o.Top corrupt.
AMU: *** exit (1) ***

AMU: *** 'install_rom' not re-made because of errors ***

Error running make install_rom on module 'HAL_BCM2835'.
Fatal error running make install_rom on module 'HAL_BCM2835'.
Batched errors...
Error running make install_rom on module 'HAL_BCM2835'.

A successful build is this, the link line is a bit different.

Starting phase install_rom ...

HAL_BCM2835 (Sources.HAL.HAL_BCM2835)...
amu -E  install_rom INSTDIR=ADFS::ROOL.$.ROOL.RPi4.BCM2835.RiscOS.Install.ROOL.BCM2835.RISC_OS COMPONENT=HAL_BCM2835 TARGET=BCM2835
link   -o linked.BCM2835 -bin -base 0xFC000000 aof.BCM2835
copy  linked.BCM2835 ADFS::ROOL.$.ROOL.RPi4.BCM2835.RiscOS.Install.ROOL.BCM2835.RISC_OS.BCM2835 FR~C~V~N
BCM2835 HAL: rom module installed

ARM Linker: (Fatal) Input file o.Top corrupt.

I think that’s a side-effect of an earlier error; if you search for *** you can easily find all the errors in a build.

In this case I suspect it’s complaining that OSAddRAM_LargeAddresses is undefined. Solution: Run an “export headers” phase (the updated kernel comes with some new definitions that need exporting). And if that doesn’t fix it, “Stamp” the Kernel.hdr folder and then run the export headers phase (the build system is dependent on timestamps to detect when files change, sometimes that can cause changes to be missed when you’re copying in files from elsewhere)

In this case I suspect it’s complaining that OSAddRAM_Large Addresses is undefined.

It does seem to be that.

Error: Undefined symbol at line 519 in file s.Top
  519 00008278         MOV     a1, #OSAddRAM_LargeAddresses

The suggested solutions did not work. A search with !Locate failed to find OSAddRAM_Large Addresses being set anywhere, all i found was is being used in HAL_BCM2835.s.top

Are you sure you’re using the right kernel sources? The LongDesc branch of my fork? https://gitlab.riscosopen.org/jlee/Kernel/-/tree/LongDesc

Are you sure you’re using the right kernel sources?

Probably not then. From the link first given I managed to find the wrong one!!

OSAddRAM_LargeAddresses is now defined and that error has now gone.

But I still get the same build failure, from a clean build. It comes with some pain.

Time: Sun Jun 28 23:01:11 2020
Location: Application space
Current Wimp task: Task Obey
Last app to start: link -o aof.BCM2835 -aof o.Top o.CLib o.CMOS o.Debug o.Interrupts o.SDIO o.Timers o.UART o.USB o.Video o.DMA o.Messaging o.GPIO o.VCHIQ o.IIC o.RTC o.SPI o.Touch o.KbdScan o.DBell o.IntVC6 o.PCI o.EtherNIC  RISCOSLIB:o.romcstubs

R0  = 00000000 R1  = 00000008 R2  = 00000003 R3  = 00000048
R4  = 00000000 R5  = 0001f1b8 R6  = 000394e8 R7  = 0001f170
R8  = 00000004 R9  = 00000001 R10 = 00021340 R11 = 00021f90
R12 = fffffff5 R13 = 00021f5c R14 = 01010101 R15 = 0000e620
DFAR = 00000008  Mode USR32  Flags nZCv if   PSR = 60000010

0000e5d8 : e28f1f70 : ADR     R1,&0000E7A0
0000e5dc : e5900010 : LDR     R0,[R0,#16]
0000e5e0 : ebfff269 : BL      &0000AF8C
0000e5e4 : e2801008 : ADD     R1,R0,#8
0000e5e8 : e8910003 : LDMIA   R1,{R0,R1}
0000e5ec : ebffec8c : BL      &00009824
0000e5f0 : e1a06000 : MOV     R6,R0
0000e5f4 : e590000c : LDR     R0,[R0,#12]
0000e5f8 : ebffe78a : BL      &00008428
0000e5fc : e3500000 : CMP     R0,#0
0000e600 : da000006 : BLE     &0000E620
0000e604 : e51b0028 : LDR     R0,[R11,#-40]
0000e608 : e28f1f67 : ADR     R1,&0000E7AC
0000e60c : e5900010 : LDR     R0,[R0,#16]
0000e610 : ebfff25d : BL      &0000AF8C
0000e614 : e2801008 : ADD     R1,R0,#8
0000e618 * e8910003 * LDMIA   R1,{R0,R1}
0000e61c : ebffec80 : BL      &00009824
0000e620 : e51b0028 : LDR     R0,[R11,#-40]
0000e624 : e28f1f63 : ADR     R1,&0000E7B8
0000e628 : e5900010 : LDR     R0,[R0,#16]
0000e62c : ebfff256 : BL      &0000AF8C
0000e630 : e2801008 : ADD     R1,R0,#8
0000e634 : e8910003 : LDMIA   R1,{R0,R1}
0000e638 : ebffec79 : BL      &00009824
0000e63c : e58d0008 : STR     R0,[R13,#8]
0000e640 : e51b0028 : LDR     R0,[R11,#-40]
0000e644 : e28f1f5e : ADR     R1,&0000E7C4
0000e648 : e5900010 : LDR     R0,[R0,#16]
0000e64c : ebfff24e : BL      &0000AF8C
0000e650 : e5900008 : LDR     R0,[R0,#8]
0000e654 : ebffe773 : BL      &00008428

R15 = 0000e620 = +6620 in application memory
R14_usr = 01010101 = +1008101 in application memory

It’s getting late, I would risk making even more mistakes.

Success! The 8GB RPi4 now has 8GB.

I cannot now reproduce yesterday’s build error, today it just worked first time.

I don’t know what went wrong. Yesterday’s build, and the ZeroPain, were from the Titanium, but today the build is fine on both the Titanium’s ADFS and the RPi4’s RAM disc.

Sorry for all the noise and thanks for the 8GB.

This is exciting news but just to confirm, is this part of the overnight build or do the technically challenged need to wait until the image is available to download?

It’s not part of the overnight build. There are still some big issues to resolve (biggest one probably being that the OS will be running with less memory protection than usual, allowing usermode to write to memory that it normally shouldn’t be able to), so the changes will probably only find their way into official builds after 5.28 has been released.

(Also for people interested in bigger RAM discs, there’s still an unresolved issue with RAMFS/FileCore that stops them from going over ~500MB)

Setting GPIO pull-ups and pull-downs doesn’t work on the RPi4. The BCM2711 uses a completely different (and much more sensible) method to control them, but the HAL doesn’t differentiate between the chips.

Also for people interested in bigger RAM discs, there’s still an unresolved issue with RAMFS/FileCore that stops them from going over ~500MB)

Would it be a simple matter (I think I know the answer) to dedicate one core to handling a 4GBytes RAM disc in one half of the total memory and a companion application handling the RAM filing system?

Would it be a simple matter

No :-)

IIRC the problem with big RAM discs is related to the way FileCore handles the layout of single-zone discs (or something like that; basically RAM discs are treated as a giant floppy?)

When I first ran into trouble I think Sprow said in an email to me that the problem was “complicated”, and since he knows more about FileCore’s disc format than me I decided that my time was probably better spent elsewhere.

If anyone wants to take a look, there’s a BigDisc2 option in the RAMFS sources that’ll switch it over to using the sector-based FileCore API (which will provide the theoretical support for >512MB discs), and you’ll also need to disable this block of code in the kernel in order to allow the DA to be resized above 508MB. The RAMFS code will also probably need checking to make sure it works with RAM discs over 4GB in size.

The BCM2711 peripherals data sheet shows, on page 12, the auxiliary registers base address as 0×7E215000, and on page 83 shows the GPIO registers base address as 0×7E215000. I’m assuming that at least one of the statements is false.

About 8GB on the RPi4

There are still some big issues to resolve

Some software might be in for a surprise when confronted with all that space.

For information only, StrongEDs 4.69f11 and 4.70a13 both complain of “Not enough memory” on editing. Zap is OK.

The good news is that in full 8GB mode Builder does build the ROM.

For information only, StrongEDs 4.69f11 and 4.70a13 both complain of “Not enough memory” on editing.

Yeah, people have mentioned that also being a problem with the 4GB Pi. I did find a repro for it (along with a similar SparkFS failure), but I haven’t yet dug deep enough to find the cause. As noted earlier, the OS tries to protect apps by under-reporting how much memory is available, so it might turn out that the problems will go away if those values are tweaked slightly.

complain of “Not enough memory” on editing.

Signed check on available memory?

StrongEDs 4.69f11 and 4.70a13 both complain of “Not enough memory” on editing

people have mentioned that also being a problem with the 4GB Pi. I did find a repro for it …

I had not seen the problem on the 4GB RPi4 so I tried a bit harder, and indeed there it is.

Open a new BaseMode window and press and hold any key. SE 4.69f11 manages 88 characters but SE 4.70a13 falls over at the first. Nothing of the sort happens on the 2GB Titanium.

StrongEDs 4.69f11 and 4.70a13 both complain of “Not enough memory” on editing

The error seems to come from the undo code which checks the amount of free memory prior to adding an undo record. This is the code fragment in question:

;------ How much flex-mem is available?

        MVN     R0,#0
        MVN     R1,#0
        SWI     "Wimp_SlotSize"
        LDR     R0,[R12,#flexroot%+flexfree%]
        ADD     R7,R0,R2        ; R7 = available for flex

        ;------ If text doesn't have undo, we can't eat from it..

        CMN     R11,#1
        Bne     ME00

        CMP     R9,R7
        MOVgt   R0,#Err_NoMem%
        Bgt     MemEnsX

        MVN     R0,#0           ; No room for undo..
        LDMFD   R13!,{R1-R12,PC}  ;

Depending on how far from 2GB the value returned in r2 is clamped and the amount of free memory in StrongED’s flex heap it will work or raise an error.

All in all there are 10 calls to Wimp_SlotSize that I’ll need to check for similar failures. David would you be willing to test an updated SE once I’ve applied any necessary fixes?

David would you be willing to test an updated SE once I’ve applied any necessary fixes?

Yes, be pleased to help.

Depending on how far from 2GB the value returned in r2 is clamped

Currently it clamps to 2GB-4KB. I was thinking of changing it to 2GB-3MB (or thereabouts) because that’ll match the upper limit on machines with 2GB of RAM (Titanium is 2GB+2MB RAM, minus 5MB for ROM), but there may still be problems because (e.g.) the actual values on a 2GB machine might normally be several MB lower than that because some of the memory will have already been allocated for other purposes.

You might want to check this list of APIs which are clamped. I should probably add this info to the wiki somewhere.

Setting GPIO pull-ups and pull-downs doesn’t work on the RPi4. The BCM2711 uses a completely different (and much more sensible) method to control them, but the HAL doesn’t differentiate between the chips.

Were you working on fixing this, Dave? I had a quick look tonight and it looks like there’s also the problem that because the GPIO HAL device updates 32 pullups at a time, it’s likely to completely clobber the pullup configuration that the SDIO driver had set up. The SDIO code should probably be changed to call through to the GPIO code. Also some of the GPIO routines are missing the DataSyncBarrier barriers.

Were you working on fixing this, Dave?

No – I don’t have a Pi 4, and I only know someone who knows someone who has one, so testing could only be at best third-hand. This leaves me in an unsatisfactory situation for coding it, much as I would like to do so.

it’s likely to completely clobber the pullup configuration that the SDIO driver had set up

No, one of the advantages of the much better interface offered by the BCM2711 is that the pullup/pulldown settings can be read back directly from the registers. No-one has any excuse for clobbering any settings. It isn’t necessary to keep a shadow copy.

Were you working on fixing this, Dave?

No – I don’t have a Pi 4, and I only know someone who knows someone who has one, so testing could only be at best third-hand.

OK, I’ll handle it then.

No-one has any excuse for clobbering any settings.

Agreed. My statement was about how things currently are, not how they should be :-)