Raspberry Pi 3

Alex: None of the currently available versions of RISC OS will work. The good news is that the ‘overnight build’ available tomorrow morning should work:-)

Thank you to those that gave the heads up on the Pi3. I had to get up at 5am (GMT) this morning for something at work. Knowing there might be a new device available, I fired up the laptop. I went onto the RS site, but didn’t follow the link to pi3. Instead I started typing “rasp” into the search box. One of the suggestions is “Raspberry Pi 3 model B.” I clicked on that and was given two options. Didn’t fancy waiting for a box of 150 of the things, so selected the single option. I chose to add a second one. On checking my basket, I’ve got two plus some other stuff I was looking at and placed in my basket (not logged in) ages ago. Deleted the other stuff. Logged in as I’ve used them for personal stuff before and now got some other stuff I was considering in my basket. Deleted that as well, but still have two RPi3. Checked out and expecting them delivered tomorrow.
Just trying again. Forget stuff in the basket, just do the search method. I’ve just changed to 20k devices, but they only have 15k left in stock! :(
I must remove from basket and not check out!

Thanks Chris, I will be ready to test it in the morning!

They’re now trying to push 2.4A through a micro USB connector

Never quite understood why the USB option was used and it’s now got to the “just fit a power connector ‘FGS’” state of affairs.

If you want alternative power in, you can just connect it through the 5V and GND pins on the GPIO header. My brother connected up the 5V line from an ATX PSU to it for more than enough current.

Can confirm that RC14 works on the Pi 3, with replacing RISCOS.IMG with this morning’s autobuild, and replacing the firmware with the latest from the Pi github repo.

Only done minimal testing, but one issue I’m getting is that the viewable screen is larger than the desktop, and so left-to-right mouse pointer movement is mis-positioned. Centre is accurate, the mouse is exaggerated to the left and to the right – ie have to put the pointer to the left of the thing being clicked on on the LHS, to the right of things on the RHS. This may be a result of using bleeding edge firmware – would be useful to know if there’s a ‘known good’ firmware version to use.

This doesn’t seem like a Pi 3 specific problem, and I didn’t change anything in CONFIG.TXT. I don’t remember seeing it on this monitor before, but I haven’t used it on RISC OS for a while, so it could be a red herring.

Hmm, looks like they might have been messing with the overscan logic fairly recently. I’ll have to take a look into it, I guess.

From MagPi Interview with Eben:
Two new features of Pi3, “direct USB mass storage and PXE network boot capabilities”.
I wonder what that means!

Hi Theo, can you post what exact files you have in your boot folder of the sdcard ? I got my RPI3 delivered today (amazingly short delivery times nowdays…), so I put the nigthly build ROM there (file dates from 22nd of February ?) and the files from github I thought that need to be replaced compared to my RPI2 boot folder but it doesn’t want to post…

…any changes needed to be made to the config files ? …may be the turbo mode from my RPI2 config,txt is not usefull any more…

My RPi3 lit up first time. I had prepared the card in the RPi2 with the latest firmware from github. (I don’t know whether that is necessary or not.)

*fx0
RISC OS 5.23 (01 Mar 2016)
*
bootcode.bin  01Feb16
fixup.dat     25Feb16
start.elf     29Feb16

disable_overscan=1
hdmi_drive=2
fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG
boot_delay=5
framebuffer_swap=0
force_turbo=1
arm_freq=900
core_freq=250
sdram_freq=450

The over-clocking is simply the values from the RPi2. What is best for the RPi3 will be sorted soon.

HTH.

As luck would have it my newly arrived Raspberry Pi 3 had just started up perfectly when I noticed a post to the gcc mailing list arrive on the iMac with an intriguing title, “UnixLib and ARMv8”. Perhaps it wasn’t a good idea but I read it.

Moving on, a simple gcc made “Hello World” ELF wouldn’t run on the RPi3.

*a/out

Fatal signal received: Illegal Instruction

Stack backtrace:

Running thread 0x14f14 (Main Thread)
  (   a7f34) pc: 47d8e49c lr: 47d8e8b8 sp:    a7f38  __write_backtrace()
  (   a7fa0) pc: 47d8e5ec lr: 47d90470 sp:    a7fa4  __unixlib_raise_signal()
  (   a7fb0) pc: 47d90324 lr: 47db80a8 sp:    a6f5c  __h_cback()
  (   a6f84) pc: 47db802c lr: 47d91cf8 sp:    a6f88  write()
  (   a6fa0) pc: 47d91c8c lr: 47d93c54 sp:    a6fa4  __flsbuf()
  (   a6fc0) pc: 47d93bcc lr: 47d93da0 sp:    a6fc4  fputc()
  (   a6fd8) pc: 47d93d50 lr:     86e8 sp:    a6fdc  puts()
  (   a6fec) pc:     86d8 lr: 47da523c sp:    a6ff0  main()

*

A bit more masochism showed that NetSurf, PackMan, Otter-browser and Qupzilla all failed similarly.

As already said the matter has been reported the gcc list.

Hi Theo, can you post what exact files you have in your boot folder of the sdcard ? I got my RPI3 delivered today (amazingly short delivery times nowdays…), so I put the nigthly build ROM there (file dates from 22nd of February ?) and the files from github I thought that need to be replaced compared to my RPI2 boot folder but it doesn’t want to post…

Try this

Two new features of Pi3, “direct USB mass storage and PXE network boot capabilities”.
I wonder what that means!

PXE boot? Think bare metal network boot. i.e. The board can boot onto a network that has a BOOTP server allowing you to keep an OS on a network resource and boot any number of boards from that same image.
Usually used in the PeeCee world to boot and load an OS onto the disc storage from a safe image.

Re: GCC/UnixLib, fortunately it looks like it only requires an updated UnixLib, and not a recompile of everything.

It looks like the thread is available here if anyone wants to follow along: https://www.mail-archive.com/gcc@gccsdk.riscos.info/msg02606.html

(Edit: Textile keeps eating the link, grr…)

It would require a recompile of everything that statically links with UnixLib, ie almost everything that uses UnixLib. Things that are built with shared libraries likely only need the shared library replacing, and possibly unaffected are things that don’t use pthreads (I’m unclear if the pthread code gets called in other situations).

This is the GCC mailing list thread, by the way

PXE boot? Think bare metal network boot. i.e. The board can boot onto a network that has a BOOTP server allowing you to keep an OS on a network resource and boot any number of boards from that same image.

It could mean one of two things:

• Either the board and boot from USB or network, without an SD card
• Or the default Linux system is shipped that way – ie boot minimal Linux, fetch kernel from the network/USB, then chain-load that.

I’ve just tested it with no SD card and there are no network lights and no traffic from tcpdump. USB boot is notoriously finnicky on PCs and my micro SD card reader doesn’t work well for BIOS boots, but I get not a sausage on the ACT light with USB and no SD, so I don’t think it’s booting bare metal there.

…tell me it was a SWP instruction.

I read that in Jeffrey’s summary yesterday and thought “there goes the one atomic read-modify-write instruction that worked on every ARM”. Now I guess semaphores will need to use something else. Hmm…

Thanks to Theo and David I got it running now also.

Doing some run’s with my different benchmarks I see some weird result affected by a very low memory speed. It almost seems that the 1st and 2nd level (data) caches are not in action, are those turned off by default somehow ?

It would require a recompile of everything that statically links with UnixLib, ie almost everything that uses UnixLib.

Argh! I haven’t really followed GCC but knew of the existence of the shared UnixLib, so I assumed that it was used by default. This looks like it could be a mess :(

Doing some run’s with my different benchmarks I see some weird result affected by a very low memory speed.

Something doesn’t seem quite right. The Raspberry Pi 3 is generally slower than the 900MHz clocked Raspberry Pi 2. My initial thought had been that the speeds were very similar but that was based on romark’s Processor test, which is the odd one out it would seem, everything else has the RPi3 as slower.

Further, the RPi3 does not appear to respond to over-clocking.

p.s. It seems overclocking is TBA, here and here

I see a major speed up in my NEON Mandelbrot (no memory transfers), but slower in all the sorting routines and much slower in my memory transfer check that uses either LDM/STM or VLDM/VSTM…something is wrong in that area.

EDIT: To give you some numbers: PI2 at 900 MHz show’s memory speed of about 2500 MByte/s with VLDM/VSTM (a littler lower with LDM/STM) when transfering 1/2/4/8 KByte chunks. Current PI3 setup only delivers around 170 MByte/s.

From the result of integer Mandelbrot I could guess it runs also slower clocked than 1200 MHz, as it shows a similar results like RPI2 at 900 MHz but that doesn’t explain that major drop in memory speed.

Pointer positioning issues when using overscan should be fixed with tomorrow’s ROM. Looks like it’s been broken for quite a while (best guess is 13th May 2015 when they made an asymmetric overscan fix to the firmware).

Something doesn’t seem quite right. The Raspberry Pi 3 is generally slower than the 900MHz clocked Raspberry Pi 2.

As I understand it, recent Pi firmware underclocks the CPU to 600 MHz and Raspbian then requests faster speeds as needed. On the Pi Zero, there are CONFIG/TXT tweaks necessary under RISC OS to get full speed.

I suppose the real question is whether overclocking is disabled on the Pi 3, or whether all custom settings are. If you manually set the 1.2 GHz speed in CONFIG/TXT then that’s not technically an overclock and hopefully still works.

Edit: The Q&A on the Pi forums states that you can still manually set the clock speed.

If you manually set the 1.2 GHz speed in CONFIG/TXT then that’s not technically an overclock and hopefully still works.

That is the bit that doesn’t work on the RPi3.

Does “force_turbo=1” work? According to the docs, that forces the old behaviour (ie. no dynamic scaling), but the docs predate the Pi 3.

@Jeffrey: I didn’t have any problems with mouse pointer setting, I guess due to my settings that disable overscan.

@Chris: My findings from above where found out while “force_turbe=1” was set, so that either doesn’t work like on the PI2 or it doesn’t fix the issues. So I think it’s not running at 1.2 GHz at the moment. EDIT: I tried combinations of “arm_freq=1200” with force_turbo on/off, no change.

Does “force_turbo=1” work?

force_turbo=1 etc does not work on the RPi3, it did on the RPi2. RISC OS on the RPi3 really does not respond to overclocking settings in config/txt.

So I think it’s not running at 1.2 GHz at the moment.

The ‘default’ value of 600MHz would appear to apply.