Raspberry Pi 4

Can I just say, please, that I don’t think it would be a great idea to host a public ROM at such an early stage because it is apt to turn away excitable newcomers who have just bought a RPi4 and want to try out this alternative free OS…but it could be useful perhaps to have one that’s password-protected and grant passwords to the old hands who know what to expect?

Personally I’m going to be doing some compatibility/analysis work on Aemulor soon for another target, and it would be very handy to be able to check operation on the Pi4 at the same time. I can probably resurrect the keyboard+mouse over UART hack that I used with the first Pi and make that available for the early experimenters here too; beta testers for Pi4/OS/Aemulor will be useful.

I think that is a long way off.

Just trying to compile a rom from the latest source tarball, without worrying about the Pi 4 to start with, I find that the ‘Prepare’ directory is missing after untarbz-ing the source. So I have copied over the ‘Prepare’ directory from a rom I built a year or so ago. Why is the prepare directory missing? The untarbz process ends with a error file ..*.Prepare.!run not found.

Anyway I do fortunately have a copy of the missing directory and I’ll try again.

Another missing directory – this time
…bcm.BCM2835.RiscOS.Prepare.^.Library.InstallTools

What is wrong please – looks like the source tarball is corrupted.

I have been very careful to follow the Beginner’s instructions for compiling a rom precisely.

The untarbz process ends with a error file ..*.Prepare.!run not found.

On moving to git there have been layout changes to the source. !Prepare is now at BCM2835.RiscOS.Apps.!Prepare, note the !. The calling code is in !UnTarBZ2.Tools.wrap.

The source code tarball is OK, it builds here without any other issue.

AFAICS building from the source code tarball will not build an RPi4 ROM. In any case all you get is the same as the current ROM download. AFAICS there may be more RPi4 ‘work in progress’ to be done and merged.

HTH.

Many thanks. The ‘Env’ folder is one directory further down but I have spotted that.

Yes, I have downloaded the bits I need to merge – the Pi3 rom seems to be building OK now. I’ll alter the files that I have downloaded as recent items in the merge bit and try for a Pi 4 rom and let you know how I get on.

Apart from being unable to find the ‘MiniUART’ setting in the file HAL_BCM2835/hdr/BCM2835, the Pi4 rom seems to be building OK. Progress report later.

Yes, I have downloaded the bits I need to merge.

That is the bit that has eluded me, what does need to be merged?

P.S. Now found an earlier post

P.P.S Those files are already merged.

That is the bit that has eluded me, what does need to be merged?

AFAIK it’s currently only the HAL that needs changing/merging.

https://gitlab.riscosopen.org/RiscOS/Sources/HAL/HAL_BCM2835/merge_requests/2

My first attempt with an SD card started up OK on a Pi3 (slow text written to screen as it was being sent through serial as well) but just got to the multi-coloured square on the Pi4.

Have done the changes in HAL_BCM2835/hdr/BCM2835, to set Debug, HALDebug and MiniUART to {TRUE} except that there is no mention of MiniUART….

Now stuck.

…I keep my fingers crossed for the RiscOS port…meanwhile looking forward to play around with that Cortex-A72 I found an interesting read here: Cortex A72 Software Optimization Guide

You’ll find all the usual latency/cycle stuff and ongoing from page 36 some special considerations. On page 38 a take on memcopy recommendations to use non writeback interleaved LDRD/STRD instructions.

Might want to hang around a bit before buying if not in a rush.

https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/#p3

The instructions on how to build a Pi 4 rom are flawed. One of the instructions is impossible: in the file HAL_BCM2835/hdr/BCM2835, it is easy to set Debug and HALDebug to {TRUE} but there is no label ‘MiniUART’ so it cannot be set to {TRUE}.

Can we have a suggestion whether this matters or not please? Should the label be added and set to {TRUE}?

Can we have a suggestion whether this matters or not please?

It does matter!

I’m not sure where you’re looking though, I can see MiniUART; it’s right there on line 51. Are you perhaps trying to find it in the BCM2835 HAL for a normal Pi, rather than the Pi 4 copy? That wont work, you need the HAL with Ben’s changes which aren’t in the nightly tar.bz2 downloads.

That is the bit that has eluded me, what does need to be merged?

Thanks for the link given above. That was the bit I had failed to work out. Having similarly failed to understand git I downloaded all of the files manually. The built ROM has lit up on the RPi4 and got to the desktop, once all the networking was disabled. (The desktop display is rather sat up with reduced contrast, black level is mid-gray.)

The ROM also works in the RPi3B+ with a correctly exposed desktop.

I don’t have the serial facilities so can’t go further.

Having similarly failed to understand git I downloaded all of the files manually.

You can clone Ben’s copy of the Pi 4 HAL and then switch to the branch he’s been working on:

git clone https://gitlab.riscosopen.org/bavison/HAL_BCM2835.git
cd HAL_BCM2835
git checkout Pi4

There’s also the “check out branch” button in gitlab, which pops up a window containing the instructions you’d want to follow if you wanted to fetch Ben’s changes into regular copy of the HAL that had been fetched from git (i.e. if you’ve cloned the whole Pi ROM product).

Or for a third option, the cloudy download button next to “check out branch” will allow you do download a patch file, which can presumably be applied to a gitless copy of the sources using a suitable copy of the ‘patch’ tool.

Finally there’s the fourth option of clicking on the “Pi4” bit of “Request to merge bavison:Pi4 into master” to arrive at Ben’s branch in gitlab, and using the download button there to download a zip/tar of his sources. But if you’re extracting it under RISC OS you’d need to find a de-archiving tool which can translate the ,xxx extensions to filetypes (presumably ROOL’s UnTarBZ2 will work with the .tar.bz2 file?)

You can clone Ben’s copy of the Pi 4 HAL and then switch to the branch he’s been working on:

That works on RISC OS.

dir 
set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/bavison/HAL_BCM2835.git  HAL_BCM2835
dir HAL_BCM2835
sgit checkout Pi4
echo finished

There’s also the “check out branch” button in gitlab, which pops up a window containing the instructions you’d want to follow

I tried that, it appeared to have merged but had not, there was no sign of the RPi4 HAL, this :-

#define Module_HelpVersion              "0.79 (25 Jun 2019) Pi4.6"

User error no doubt.

Finally there’s the fourth option of clicking on the “Pi4” bit of “Request to merge bavison:Pi4 into master”

It’s just knowing which button to poke!! I do use UnTarBZ2 for file translation between the Mac and RISC OS.

Thanks for the help. Four options and I didn’t find any of them!

Rpi4 usb-c hardware problem may be worth reading before you buy. Whether relevant to RISC OS I do not know.

Reading the report on The Register – it’s a hardware issue that affects powering the Pi unless you use the ‘right’ USB-C cables. Nothing to do with the OS it runs at all.

The USB-C issue is a non-issue if you use either the official RPi power supply or your old microUSB power supply with an adapter. And if something goes wrong, the RPi will not start up at all, so it is easily identified. Really only a slight hiccup in the grand scheme of things if you ask me.

Are you perhaps trying to find it in the BCM2835 HAL for a normal Pi, rather than the Pi 4 copy? That wont work, you need the HAL with Ben’s changes which aren’t in the nightly tar.bz2 downloads.

I am downloading the source tarball for the Pi and then working out what to change. The link to the updated HAL should help. I’ll try again.

Have changed the files in Sources/HAL/HAL_BCM2835 that are recent, recompiled the rom but it still doesn’t work. Any more suggestions?

In another topic, I noted that the Ras Pi 1 would not fit in my chosen cases; whereas all later versions of the Pi would all fit in the same case design.)

Until the Pi 4 arrived. Only the GPIO pins are in the same place. I don’t have a camera and who really uses the DSI display connector?

Some romarks from the RPi4. FWIW!

Test                                       Titanium    RPi3B+      RPi4
Processor - Looped instructions (cache)     3712545   2852011   3588423
HD Read - Block load 1MB file                 76039     22866     22086
HD Write - Block save 1MB file               103413      3683      3737
FS Read - Byte stream file in                  1383       675       707
FS Write - Byte stream file out                1393       157       162

It is the same, not very exciting Maplin, partitioned SD card used in both Pi’s, the filing system results are for SDFS. The Titanium filing system is ADFS. The useful comparison will be Titanium ADFS v RPi4 USB3, but this is not expected this week. (I am sure I saw somewhere that the RPi4 SD was faster.)

Uhhhh… The Titanium is slower at reading than writing?

That’s pretty normal for risc os, rick. I suspect it is something to do with handling of scatter lists, but for whatever reason, writing tends to be simpler/faster than reading when dealing with high speed devices. Essentially, RISC OS incurs more overheads, and IIRC there was also more need to do cache control / memory barriers etc on the reads.

and who really uses the DSI display connector?

Does RISC OS even support using DSI? There seem to be a few display panels, around 800×480(ish) resolution, but they’re pricey (around €50 on promo, closer €80 normally). For that kind of money you can get a better resolution with HDMI input.

I suspect DSI might be a bit of a leftover from the Pi’s heritage? Or maybe it’s “a thing” in the mobile phone/embedded media player sectors?

The Titanium is slower at reading than writing?

On that drive and on that test, yes. However the other two ADFS SSDs in the Titanium do not show that slow read on running the same test.

That’s pretty normal for risc os, rick. I suspect it is something to do with handling of scatter lists, but for whatever reason, writing tends to be simpler/faster than reading when dealing with high speed devices.

Certainly for my Crucial SSD drives, they have on-board RAM to act as a disc buffer. A write is then regarded by RISC OS as complete once the last byte has been accepted into the RAM buffer. The drive continues to write it to the SSD medium. Less of an effect on reading because the data being read are not ready beforehand.