Raspberry Pi 3

I don’t think this test does justice to the real-world speed differences between the Iyo and Pi hardware …

(see below)

I don’t think this test does justice to the real-world speed differences between the Iyo and Pi hardware …

The ‘tests’ are wholly different tho’ – I can vouch for what you say about graphics performance – I’ve tried similar things with similar results.

It would be good if we could test Aemulor on the Pi3. But we need a non ZPP/High vectors build. If anyone has one they could send us we will ‘buy’ a copy of Aemulor and test it.
Adrian doesn’t seem to be around at the moment and I don’t want to bother him unnecessarily.

Time to roll your own by changeing two Lines in BuildSys.Components.ROOL.BCM2835
Change (1)
#Kernel -at 0xFC010000
Kernel -at 0xFC010000 -options ASFLAGS=“-PD \”HiProcVecs SETL {FALSE}\""

Change (2)
#FPEmulator -options FPE_APCS=3/32bit FPEANCHOR=High
FPEmulator -options FPE_APCS=3/32bit
This will build a Non ZPP version of the rom

It would be good if we could test Aemulor on the Pi3. But we need a non ZPP/High vectors build. If anyone has one they could send us …

emailed

Rob: We do most things here, but programming in C is not one of them. Learning C is on my to do list but at the current rate I’ll have the time in about 2036.
David: Thanks

Learning C is on my to do list but at the current rate I’ll have the time in about 2036.

If that’s your projected retirement there are two things to consider:

1. You’re busier when retired
2. the Tories plan to work everyone to death

Rob: We do most things here, but programming in C is not one of them.

Are you referring to Rob’s two changes? If so, the changes are not C (though it looks a little bit like it), they are for the assembler preprocessor.

The first question is – can you build your own ROMs? I recall a custom build of Switcher (re. the power off), so somebody somewhere can build components. Only components, or the entire OS?

If the entire OS, then you’ll need to look in the platform specific directory (this is “BCM2835Dev” for the Pi build) and then look inside the “BuildSys” directory. Within that is a “Components” directory, and then a “ROOL” directory. Yup – a LOT of directories.

Or in easier to read terms: …[buildtype].BuildSys.Components.ROOL where [buildtype] is BCM2835 or OMAP3 or OMAP4 or whatever.

Inside there are build details for each of the platforms. Open the corresponding file for the platform you are concerned with.

About a windowful down (if you are using the default Edit window size) you’ll see a line that says this:

# kernel is first module in ROM seen as the UtilityModule

Two lines down, is this:

Kernel                -at 0xFC010000

Change it, as indicated by David, to say:

Kernel -at 0xFC010000 -options ASFLAGS="-PD \"HiProcVecs SETL {FALSE}\""

Then go down a bit further until you see the line:

FPEmulator            -options FPE_APCS=3/32bit FPEANCHOR=High

this should be changed to:

FPEmulator            -options FPE_APCS=3/32bit

You need to change the kernel so it actually knows that Zero Page should be at zero, and then tell FPEmulator so it doesn’t blow up during system startup. ;-)

Save the file, then run the entire build process from scratch (from the clean and export phases).

That should give you a non-ZPP build.

• Hint: Maybe it might be an idea to save the original with a ZPP suffix, like “BCM2835ZPP” so you can use !Builder to easily switch between building a ZPP and a non-ZPP version?

• Hint: You probably don’t need to perform a full build. In theory only the kernel and FPE need to be changed… however in the absence of knowing side effects, I’d recommend a full build, leave experimentation to another day.

@Chris, email resent.

The first question is – can you build your own ROMs?

Not really. Well I do have ROOL’s development kit in stock! I did about 20 years ago try installing Acorn’s C but couldn’t get “Hello World” to work and moved on to other things.

I do know it only takes the editing of two ‘command’ files to satisfy my current needs. It’s installing, learning how use some form of CVS? and run the compiler that I’d have to learn. I think my time is best spent getting the two versions of the RapidO fully tested and launched. (Nearly there now!)

Chris: I never did manage to get the CVS setup working. Admittedly I didn’t try terribly hard, as I could just unpack a source snapshot, mod the bits I want changed, then build.

Take a look at this: http://www.heyrick.co.uk/blog/index.php?diary=20131105

I never did manage to get the CVS setup working.

Partial success here, I have managed to checkout components using !CVS, the following example is for the ZeroPain module.

dir <obey$dir>
set UnixEnv$cvs$sfix ""
set alias$cvs <obey$dir>.!CVS.Bin.cvs %%0
echo "Started"
cvs -z 9 -d :pserver:anonymous:@riscosopen.org:/home/rool/cvsroot co bsd/RiscOS/Sources/Programmer/ZeroPain
echo "Finished"

ROOL’s !Builder needs to have been seen to do the build.

Credits, this information was garnered from other people’s posts on this forum.

Notes !CVS requires “alignment exceptions” to be off and as it uses UnixLib does not currently run on the Raspberry Pi 3.

Attempting to checkout a build environment using RISC OS didn’t go too well, leading to the conclusion that that probably does have to be done on Linux.

To echo what has already been said, the ROM build does turn out to be easy though it certainly doesn’t seem so at first. ROOL’s Builder environment is excellent, a simple front end over all the complicated stuff.

@Rick, minor comments.

and it only looks for the image “SDFS::0.$.!Boot.Loader.riscos/img”

See the SDCMOS module :-

BCM2835Dev.cddl.RiscOS.Sources.HWSupport.SD.SDCMOS.s.sdcmos

NonCanonicalisedPath
        =       "SDFS:$.!Boot.Loader.riscos/img", 0
NonCanonicalisedPath2
        =       "SDFS:$.riscos/img", 0

Building on a RPi2 can be hurried up a lot by using its maximum 512MB RamDisc. That is not quite big enough to do the whole job in one go. Once the unpack is complete, stop the process in the running script. BCM2835Dev has been created at this point, the tar and bz2 files are no longer required and can be removed to make the necessary room. Then continue by running BCM2835Dev.Prepare.!Run. The build is about 10 minutes on a 900MHz RPi2. (The RPi3 is a no-no due to UnixLib build components ATM.) A Titanium or IGEPv5 will be at least twice as quick.

As part of our SATA driver testing it was suggested UnTARing the RISC OS sources!

Two issues:
‘ADFS::240GB_SSD.$.test.cvsroot.*.Prepare.!run’ not found

The first failure was the ‘*’ which assumes there are no other directories in the cvsroot directory and the * isn’t needed at all as its cvsroot.Prepare

Then the file name is mangled
ADFS::240GB_SSD.$.test.cvsroot.Prepare.!Run,feb,v

What should !UnTarBZ2 Untar options be?
Seven are ticked, all apart from Calculate file checksum
“Set ,hex filetype” and “remove ,hex filetype” seem contradictory to me!

Chris: did you read my blog article?

By the time you see that error, everything is unpacked (if you left the options alone).

The filename is mangled. Don’t know why. Just find and run the prepare file manually.

Chris: did you read my blog article?

No. I’m not attempting to actually build ROMS just find some easy to do disc intensive tasks for disc driver testing. I just thought it worthwhile to mention my experience.
Is the * is a bug?

n.b. did you get my email re CJELED?

No. I’m not attempting to actually build ROMS just find some easy to do disc intensive tasks for disc driver testing.

Well, building the ROM is pretty good thrashing for everything. ;-)

Is the * is a bug?

Yes, though I’m not sure where. It isn’t “mission critical” thankfully.

n.b. did you get my email re CJELED?

Recently? If so, no. The last email I have from you is 28th August discussing graphics tablets. The last regarding CJELED (and printer drivers) was on 10th July, you were going to let me know how v0.07 behaved.
If there is anything new, could you please resend the email. Thanks.

Is there a sure fire way of getting a Raspberry pi 3 to boot into Risc OS? I’ve tried just about everything I’ve read using Google (downloading Risc OS, buying a Risc OS micro SD card, editing Config.txt) and always the same (a large rainbow-coloured square on the monitor with a small coloured square top right). My pi 3 boots perfectly using NOOBS – both a downloaded image and a bought micro SD card. I would try throwing salt over my shoulder and sacrificing a chicken but I can’t find a chicken.

Hi Geoff,

I’ve just managed it this afternoon. What I did was start from scratch…

I used a 1st revision Pi to do the setup.

It involves accessing two SD cards at once – so a USB→SD adaptor is helpful.

1) Download the RC14 disc image. Make a new SD card using the RC14 disc image – this sets up the filesystem for you etc.

2) Now fetch the latest RISC OS ROM, and replace the ROM file on the micro SD card with yesterday’s ROM. This ensures that the ROM is compatible with the new Pi.

3) Now go onto Google and look up Raspberry Pi firmware. The first link should point you to GitHub where you can fetch the latest firmware for the Pi. Go into !Boot.Loader and replace the files Bootcode/Bin, Fixup/Dat and Start/ELF with the files from that download.

4) Next fetch the latest HardDisc image (which should have some Zero page fixes from since the RC14 release and be more ‘Pi3 friendly’ in theory). Copy that over the HardDisc image that you have.

5) Now go into !Boot.Choices.Boot.Tasks. The last file in there is a Welcome script. Remove that – it tries to load NetSurf, which crashes on booting to the desktop.

The image should be ready to go.

Now at present I still have the multicoloured square in the top corner of the screen after booting. I haven’t got the actual display mode right yet – some tweaking of the Config/TXT needed. And I still need to sort Zap and have a read to find the likelihood of a functional NetSurf and other Apps (also want to see how Jon Abbott has got on with ADFFS on the Pi3).

As part of our SATA driver testing it was suggested UnTARing the RISC OS sources!

I use a particular BCM2835 build, the 31-Jan-2015 BCM2835 tar/bz2 source tarball and it unpacks (using !UnTarBZ2 version 1.06a2) and compiles OK on all platforms (except Pi model 3 and, so far as my patience goes, Risc PC). I use the time in my benchmarks, using both hard disc and, on platforms with a 500MB RAM disc, using RAMfs.

What should !UnTarBZ2 Untar options be?
Seven are ticked, all apart from Calculate file checksum

Correct. Also radio button ‘source code defaults’ is ticked.

Is there a sure fire way of getting a Raspberry pi 3 to boot into Risc OS?

I’ve just managed it this afternoon …

I’ve had it going since 17th March. I would have commented sooner, but I wanted to ensure that it was all running in a good environment.

The 2.5 amp PSU turned up today, so I decided to update everything. I overwrote the HardDisc4 files as described and installed ZeroPain before starting.

It’s now running with the updated GitHub files from this afternoon plus the RISC OS ROM image from BCM2835Dev.5.23 dated 23 ‎March ‎2016, ‏‎04:25:23. I updated the SD card in Windows and put it back in the Pi. It simply up and ran.

It’s still a bit delicate tho’ – the little rainbow square is now present – it wasn’t before. It gives an AODT when I press f12 for the command line, but a second press of f12 works fine. After its first Boot up there was an AODT when I selected ‘Shutdown’ from the switcher menu. I haven’t tried Zap yet, but I’ll report progress later.

the little rainbow square is now present – it wasn’t before

That happens here, it is a bit weird. It is supposedly an under-volt warning but happens with the recommended PSU and two others here. Anyway adding an avoid_warnings setting to CONFIG/TXT gets rid of it and also allows the RPi3 to be run at the full 1200MHz, as previously discussed

[pi3]
avoid_warnings=2
force_turbo=1
arm_freq=1200
core_freq=500
sdram_freq=500

Thanks. Just the ticket! I’m now running my data processing tests on it for a few hours. NB must remember that ‘Reporter’ is running.

have a read to find the likelihood of a functional NetSurf

Please try NetSurf CI build #3460 or later, and let us know if it works – it is expected to.

Please try NetSurf CI build #3460 or later, and let us know if it works – it is expected to.

It does indeed. And nicely too at a clock of 1200MHz.

Good news, and thanks to all concerned.