Pico build

When building the Pico ROM, using the latest BCM2835 source tarball it throws an error that ARMBE cannot be found. I think that similar errors related to MimeMap and GPIO have been fixed.

I am told that ‘checking it out with CVS’ works, something that I haven’t yet mastered under RISC OS.

Is it sufficient simply to add the ARMBE module in the place where it says it can’t find ARMBE (that is castle/RISCOS/Sources/Programmer/ARMBE) before starting the compliation?

Well that didn’t work. Also ColourPickerOpenDialogue, MimeMap errors as well.

When building the Pico ROM, using the latest BCM2835 source tarball it throws an error that ARMBE cannot be found.

I had a quick look and the snag seems to be that there is no specific Pico source tarball, component and other files would need some work to enable a Pico build. So that got put to one side.

I am told that ‘checking it out with CVS’ works, something that I haven’t yet mastered under RISC OS.

I haven’t mastered that with RISC OS either! “This is best done from a Linux or Cygwin machine” it says here so I did, on Xubuntu. Building the Pico ROM did just work, but slightly disappointingly it didn’t actually run on the RPi3. All I got was the large multicolour square. I just planted the Pico ROM as RISCOS/IMG onto a working RPi3 card with no other changes.

As a further check a RPi ROM was checked out from CVS on Xubuntu and that did run on the RPi3.

Pico Build starting from BCM2835Dev, and DDE26

Download BCM2835Dev
Rename   BCM2835Pico
Add      Products.BCM2835Pico.modules (from cvs)
Add      BCM2835Pico.castle.RiscOS.Sources.Programmer.ArmBE (from cvs)

ARMBE failed to build :-

ArmBE (castle.RiscOS.Sources.Programmer.ArmBE)...
amu -E  -k export PHASE=hdrs COMPONENT=ArmBE TARGET=ArmBE 
AMU: failed to read time stamp for 'o.'
AMU: failed to read time stamp for 'o.'
Error running make export (hdrs) on module 'ArmBE'.

Fortunately I had had a look at “this bug”: https://www.riscosopen.org/forum/forums/4/topics/4018?page=1#posts-51347 and confirmed it. My workaround was to copy the working DDE25 CModule MakeFile, renamed as CModule25, into my copy of DDE26. This CModule25 needed to be manually copied into the BCM2835Pico environment and the ARMBE MakeFile suitably munged.

# Makefile for ArmBE

COMPONENT = ArmBE
RES_OBJ =
CMHGFILE =
OBJS = ArmBE
HDRS =
CUSTOMRES = custom

include CModule25

# Dynamic dependencies:

The Pico ROM built to completion and by way of a bonus it actually ran on the RPi3.

That begs the question as to why yesterday’s Pico CVS checkout had built the ARMBE module.

This is down to differing CModule MakeFiles.

From yesterday’s CVS checkout, BCM2835Pico.castle.RiscOS.BuildSys.Makefiles.CModule the version is :-

$Id: CModule,v 1.9.2.3 2015/02/12 20:30:56 rsprowson Exp $

Whereas from DCM2836Dev, broken, it is :-

$Id: CModule,v 1.18 2015-08-02 08:28:13 rsprowson Exp $

The DDE25 variant, working, is :-

I am told that ‘checking it out with CVS’ works, something that I haven’t yet mastered under RISC OS.

I haven’t mastered that with RISC OS either! “This is best done from a Linux or Cygwin machine” it says here so I did, on Xubuntu. Building the Pico ROM did just work, but slightly disappointingly it didn’t actually run on the RPi3. All I got was the large multicolour square. I just planted the Pico ROM as RISCOS/IMG onto a working RPi3 card with no other changes.

If you did “checkout BCM2835Pico” then you would have got the sources for the most recent Pico build (February 2015).

For each ROM there are usually two products files available – e.g. BCM2835Dev and BCM2835. The “Dev” one will generally specify component versions as being “HEAD”, with the net result that it will always use the latest code from CVS. The non-Dev one will have specific version numbers for each component, and will correspond to the most recent stable build (and by specifying the -r option to checkout you can fetch the source corresponding to older builds).

With the Pico there’s only the non-Dev version of the products file available. Using BCM2835Dev as a substitute makes sense, but as you’ve spotted that currently doesn’t pull in ARMBE, and ARMBE doesn’t build with the latest version of the shared makefiles.

If you did “checkout BCM2835Pico” then you would have got the sources for the most recent Pico build (February 2015).

That’s the one. That, possibly, is why the resulting build did not run on the RPi3, which needs later ROM components.

The ROM I made, using the current development BCM2835 source tarball, selecting BCM2835Pico as the build environment and downloading the ARMBE directory separately, file by file, using the ‘download’ link and sorting out the file types and stray trailing characters, did work on the Pi 3, including ‘EDIT’ from BASIC. Although I couldn’t get MODE 7 to work – still working on that.

downloading the ARMBE directory separately, file by file, using the ‘download’ link and sorting out the file types and stray trailing characters

I managed to avoid that as I had previously checked out the source directly from CVS using Xubuntu, I purloined the ARMBE directory from that. (The bones of the job are to checkout in Linux, ‘tar’ it to form a ‘tar.bz2’ which is transferred to RISC OS for the build.)

Although I couldn’t get MODE 7 to work – still working on that.

My build didn’t seem to know about MODE 7 either. That’s as far as I got, a rather interesting parcel of the metallic sort turned up at that point.

Although I couldn’t get MODE 7 to work – still working on that.

Now fixed on roms after 1st June.