Big batch of kernel changes

Yesterday I found the time to finish up and check in a bunch of kernel changes which had been sitting on my computer for the past few months. They’re mostly “behind the scenes” changes that shouldn’t alter the behaviour of programs or introduce new features, but they’ll almost certainly cause issues for software that does things on a low-level (particularly page table manipulation) like Aemulor or ADFFS. To a greater or lesser extent these changes will affect all machines, so if you see any new and unusual behaviour then either let myself or the relevant person know!

Main changes:

• Reimplement AMBControl ontop of the PMP system
• Place restrictions on the use of cacheable doubly-mapped areas (thread)
• Make MMU_Changing ARMops perform the sub-operations in a sensible order
• Implement support for cacheable pagetables (stats)

but they’ll almost certainly cause issues for software that does things on a low-level (particularly page table manipulation) like Aemulor or ADFFS.

I think Aemulor is already broken as a result of other changes (like zero page), as for ADFFS, I think Jon is expecting the change.

Holiday period coming up¹ so plenty of time for people to check what they have in the changed OS. Except those with a Titanium system cos the build doesn’t include the changes.(yet?)

¹ Or started because I have way too much left and a big project due in the Feb/March period. This of course means I have instructions from the 4th most senior manager (three cats take places 1-3 in the hierarchy)

Presumably if the changes which broke Aemulor are either not adjusted so that they don’t break Aemulor or some help is given to fix Aemulor, these latest changes are only of academic interest to users who will stick with a version of RISC OS prior to June 2016. As far as I am concerned, Aemulor is essential so I am forced to ignore these changes at present.

If Adrian needs any help working out what’s changed, or has any requests for how the OS can make things easier for Aemulor, then I’m sure he knows where to find me. But I haven’t heard anything from him in the past few months, so I’m not really sure what the current situation is.

There will be some more changes coming in the future which will have more far-reaching consequences (mainly stopping the use of OS_Memory 0 for DMA and making memory management SMP-friendly), but they’re going to be a few months off at least.

Is this build Pi3 compatible? Testing the same SD card on Pi1/2/3, it works on 1/2 but fails horribly on the 3, it doesn’t look like its even getting to the post screen.

The only change here that’s likely to break ADFFS is the restriction on cache enabled double-mapped buffers. It uses one for the sound as it’s quite memory intensive, with several passes on the buffer.

Is this build Pi3 compatible?

It starts up, and runs, OK on my RPi3, (and Titanium).

It doesn’t like mine, the screen fills with random dots and slowly fades to white!

It doesn’t like mine, the screen fills with random dots and slowly fades to white!

My RPi3 started up in Mode 15 which was not well displayed on my monitor, previously it started in 1920×1080. This will be due to this change which predates Jeffrey’s changes. I changed the configured Mode to 32 which tidied the start up display somewhat. Random dots and a fade to white, that does seem most odd. Does that go away with an earlier ROM? As I understand loads of new stuff has been added but mostly not actually activated.

CONFIG/TXT

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

firmware

bootcode.bin  31May16
fixup.dat     11Oct16
start.elf     13Oct16

Or put another way, I don’t know!

It doesn’t like mine, the screen fills with random dots and slowly fades to white!

Does it happen with BootFX unplugged? If you can get far enough to configure the CMOS in the first place, that is :)

Thinking it may be firmware related, I updated the firmware to the latest, which made no difference. To double check, I put the SD into both a Pi1 and Pi2, which both booted without issue.

As I said, I doesn’t get to POST on my Pi3, so it’s not configuration related. It may of course be unrelated to this change, I’ve rolled back to Oct 27th, so it could be anything after that date causing the issue. If someone could eMail me the build prior to this update, I can quickly confirm if it’s related or not.

In the end, I tested ADFFS on the Pi2 and sure enough it errored trying to create the Sound buffer. I’ve corrected this for the next release, which is due out on the 21st Dec.

If someone could eMail me the build prior to this update

Pi ROM from 5th Dec is here

I have one from 11 Dec. It’s low vector.

Thanks David and Chris. 5th works okay, the 11th has the issue, so it’s unrelated to Jeffery’s changes.

Looking through the change history, I’d say it’s likely to be the change to BCMVideo 0.40 that went in on Saturday 10th Dec. So I suspect a build from the 9th Dec will be the last without the issue

EDIT: I’ve created a separate Bug thread with a YouTube video of what happens.

Place restrictions on the use of cacheable doubly-mapped areas (thread)

Is it possible to create a cachable double-mapped DA that’s non-executable on ARMv7? Should there be a flag to indicate the DA is non-executable?

Yes. You need to use the new, system-dependent access privileges

E.g.

SYS "OS_Memory",18,%110110,%111111 TO AP : REM user+priv r+w, non-executable
SYS "OS_DynamicArea",0,-1,4096,-1,AP+64,4096,0,0,"test" TO ,DA : REM Create doubly-mapped DA