Need help getting started with RO builds (DDE31c, RPCEmu)

I must be doing something very wrong here. My endgame is to somehow build the ROOL IOMD32 branch for the Bush set-top box (the “Lazarus” machinetype) — but for now I’m settling for a basic IOMD32 build.

I’m following the instructions from here: https://www.riscosopen.org/wiki/documentation/show/How%20to%20build%20RISC%20OS on an RPCEmu (running RO4.02 “Virtually Free, for emulators” edition) emulated StrongARM RISC PC.

I checked the code out of Git into HostFS, then ran the Prepare script. It can’t seem to see my AcornC/C++ / SetPaths install. But it can’t find SetPaths: “Please make sure you have run the AcornC/C++.!SetPaths application. Try double clicking it.” (I’d done that already)

Digging in a bit deeper, the RiscOS.Library.InstallTools script (called by Prepare) seems to want an environment variable called SetPaths32$Dir to be set up.
But !SetPaths sets up SetPaths$Dir…
I think I’ve worked around this by doing a quick “Set SetPaths32$Dir <SetPaths$Dir>” in a Taskwindow, then re-running Prepare. That worked.

The first build I did after Prepare-ing the build tree failed spectacularly. When I selected the “environment” in Builder, I got a “No writable memory at this address” error, which was fixed by bumping the Wimpslot up to about 3MB and restarting Builder. Sadly the build still failed with a bunch of header file errors.

I rebooted the emulator, bumped up the Wimpslot to 3MB and started Builder again — the second build succeeded (in that I got a 4MB ROM image) but I got a few odd build errors…

do <Perl$Dir>.perl Build:Hdr2H hdr.VduExt <cexport$dir>.Global.h.VduExt
hdr.VduExt:193: Unrecognised line: ModeSelector_MaxSize    *       ModeSelector_ModeVars+(NumModeVars * 8)+4 at Build:Hdr2H line 322, <IN> line 193.

do <Perl$Dir>.perl Build:Hdr2H hdr.HighFSI <cexport$dir>.Interface.h.HighFSI
hdr.HighFSI:297: Unrecognised line: OSFind_ReadFile *       open_read  :OR:  open_mustopen  :OR:  open_nodir at Build:Hdr2H line 322, <IN> line 297.
do <Perl$Dir>.perl Build:Hdr2H hdr.LowFSI <cexport$dir>.Interface.h.LowFSI
hdr.LowFSI:151: Unrecognised line: fsinfo_notforMultiFS    * :NOT: fsinfo_flushnotify at Build:Hdr2H line 322, <IN> line 151.
hdr.LowFSI:206: Unrecognised line: fsopen_DeviceIdentity   * &FFFFFFFF  :SHR:  (32-27) at Build:Hdr2H line 322, <IN> line 206.

Winding back onto something resembling a point …

• Why am I having issues with SetPaths – is this a bug?
• Is there a missing step in the build instructions – i.e. that you need to reboot after running Prepare but before running Builder?

Cheers
Phil

It sounds like you might be using older revisions of the submodules. The command “git submodule update —init —remote” will check out all of the submodules at the most recent revision instead of the one associated with the parent repository.

Thanks for that, Cameron. Looks like that got the Prepare script working.

Builder is still throwing “no writable memory at this address” errors if I don’t increase the Wimpslot – perhaps that needs an increase. I had it set to 640K in the Switcher.

SpriteExtend seems to be failing to link on the “all” repo:

SpriteExtend (Sources.Video.Render.SprExtend)…
amu -E install_rom INSTDIR=HostFS::HostFS.$.riscos_bushstb.RO5_ALL.RiscOS.Install.ROOL.IOMD32.Video COMPONENT=SpriteExtend TARGET=SprExtend
amu -f util/mk COMPONENT=genyuvtabs THROWBACK=
link -o utils.genyuvtabs o.genyuvtabs <Build$HostLibs>.CLib.o.stubs
ARM Linker: (Warning) Attribute conflict between AREA stubs(Stub$$Code) and image code.
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Warning) Attribute conflict within AREA C$$code
(conflict first found with stubs(C$$code)).
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Error) Undefined symbol(s).
ARM Linker: __assert2, referred to from o.genyuvtabs.
ARM Linker: Errors in link, no output generated.
ARM Linker: finished, 4 informational, 2 warning and 1 error messages.
AMU: * exit (1) *
AMU: * ‘all’ not re-made because of errors *
AMU: * exit (1) *

I’ve been able to build from the “IOMDHAL” product repository (without doing the submodule update), but that seems to be a bit behind the “all” repository (notably it’s missing the IZipFS drivers).

perhaps that needs an increase. I had it set to 640K in the Switcher.

I think you need around (at least) 3MB for the tools to work correctly.

Builder is still throwing “no writable memory at this address” errors if I don’t increase the Wimpslot

That looks to be a “feature” of using OS4.02 on RPCEmu, on the Titanium with OS5.29 the build built with the default 640K Next WimpSlot. (Increasing Builder’s WimpSlot does not help.)

An IOMD32 build on OS4.02 RPCEmu, with DDE31c, from the All product, with submodules updated, the current version of OS5.29 that is, completed without any issues. The SpriteExtend link worked.

SpriteExtend (Sources.Video.Render.SprExtend)...
...
link  -o utils.genyuvtabs o.genyuvtabs  <Build$HostLibs>.CLib.o.stubs
squeeze  utils.genyuvtabs
...
SpriteExtend: rom module built

640K was the default, I increased it to about 3MB. I don’t think that’d explain the link error, though.

I’m trying to figure out how you got it working, David — could you possibly share your build log somewhere, so I can compare it with mine?
I’d like to see what compile flags are being used for the “genyuvtabs” C file.

It looks like mine are:

amu -f util/mk COMPONENT=genyuvtabs THROWBACK=
do mkdir -p o
create o._dirs
%cc -apcs 3/32bit/fpe3 -cpu 3 -memaccess -L22-S22-L41 -c -depend !Depend -DRISCOS -DASMHUFF -ff -fah -o o.genyuvtabs c.genyuvtabs
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
link -o utils.genyuvtabs o.genyuvtabs <Build$HostLibs>.CLib.o.stubs
ARM Linker: (Warning) Attribute conflict between AREA stubs(Stub$$Code) and image code.
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Warning) Attribute conflict within AREA C$$code
(conflict first found with stubs(C$$code)).
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Error) Undefined symbol(s).
ARM Linker: __assert2, referred to from o.genyuvtabs.
ARM Linker: Errors in link, no output generated.
ARM Linker: finished, 4 informational, 2 warning and 1 error messages.
AMU: * exit (1) *

Builder is still throwing “no writable memory at this address” errors if I don’t increase the Wimpslot – perhaps that needs an increase. I had it set to 640K in the Switcher

640kB is plenty, but the important bit is that RISC OS 5 will automatically resize the app slot when an AIF is loaded with a big RW/ZI claim, the slot only needs to be big enough to load the binary, which in this case is srcbuild which is ~24kB. This was added to FileSwitch in 2013, so if you’re using RISC OS 4 or 3 you’re reduced to manually setting Next.

I’ve been able to build from the “IOMDHAL” product repository (without doing the submodule update), but that seems to be a bit behind the “all” repository (notably it’s missing the IZipFS drivers).

I think you might be being lured onto the rocks with terminology here. The ‘All’ product exists only because Git doesn’t know how to recursively check an entire tree out (like CVS did if you just typed cvs co), so ROOL created a dummy repository which merely contains every published component. It is not a product in itself with any buildable output.

So “make all” isn’t meaningful.

You need to have a real product (like IOMD32) which selects all the right branches and components. Since no active product or nightly build has any need for a parallel port Zip disc, nothing references IZipFS. Often there’s a local !MkRam taskobey file kicking around in the component to manually build it, but to have Builder do something you’ll need to make a Components file, or as a short term hack you can just hijack another preexisting one that’s close enough like IOMD32.

ARM Linker: (Warning) Attribute conflict between AREA stubs(Stub$$Code) and image code.
ARM Linker: (attribute difference = {32bit}).

This says you’ve built something as 26 bit and are trying to link it with 32 bit stubs (or vice versa). What environment did you select in Builder?

could you possibly share your build log somewhere

My build log is here

A simpler debug may be to build the SpriteExtend module on its own. Preselect the build environment only in Builder, do nothing else there. Increase Next to 4K. Build with the TaskObey file in the SprExtend source directory.

My endgame is to somehow build the ROOL IOMD32 branch for the Bush set-top box (the “Lazarus” machinetype)

I assumed that All was being used for the Lazarus sources but that is present in IOMDHAL. In that case git can be avoided by downloading the IOMDHALDev source code archive and unpacking that with UnTarBZ2.

ARM Linker: (Warning) Attribute conflict between AREA stubs(Stub$$Code) and image code.
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Warning) Attribute conflict within AREA C$$code
(conflict first found with stubs(C$$code)).
ARM Linker: (attribute difference = {32bit}).
ARM Linker: (Error) Undefined symbol(s).
ARM Linker: __assert2, referred to from o.genyuvtabs.

Linking against an old 26-bit o.stubs ?
As David says, better to download the IOMDHALDev source code archive and follow the instructions from here since it comes with the compiler and tools versions required to build ROMs and modules.

A ROOL developer has pointed out to me by email that from the build log there is something odd about the IOMD ROM I built from the All product. The ROM is unexpectedly bigger than it should be.

Long story short, the All product has the ‘wrong’ version of ScrSaver in it. Screen savers do not work in that All build.

The two versions of ScrSaver are :-

#define Module_HelpVersion      "0.14 (01 Aug 2015) 1.9.2.4"

#define Module_HelpVersion      "0.22 (14 Jan 2012)"

Make a careful study of the dates and version numbers.

The one that works is the later dated version.

Entertainingly git insists on showing the wrong version.

That version number mismatch may be messing something up.

Beware of the All product.

Long story short, the All product has the ‘wrong’ version of ScrSaver in it. Screen savers do not work in that All build.

To expand on this, the ROM products are tracking the Ursula branch of the ScrSaver repository, while the All product is tracking the master branch which contains some unmerged work done for NCOS in 1999-2000 (mainly related to printing and allowing some hardcoded constants to be configured, as well as a test program and some new graphics).

To expand on this, the ROM products are tracking the Ursula branch of the ScrSaver repository

Thanks for that.

The catch was, as described by sprow earlier, that All is not intended to be a Product in the sense that the buildable ROM and Disc Products are. That was not obvious.

.gitmodules clearly shows that ScrSaver is in the Ursula branch.

submodule "RiscOS/Sources/Video/UserI/ScrSaver"]
	path = RiscOS/Sources/Video/UserI/ScrSaver
	url = ../../RiscOS/Sources/Video/UserI/ScrSaver.git
	branch = Ursula

(That example is from BCM2835 which I just happen to have a clone of on the Mac, which has the git hidden files.)

One should not build products from All, which is all from master, as the product may require submodules from other branches. I was not noticeably aware of that either.

At least is now clear why that IOMD ROM built from All was the wrong length.

@Sprow – I’m using the “ROOL.IOMD32” environment. It’s a “git clone —recursive” from the “All.git” repository – see below for the full set of commands.

The HostFS itself has two C/C++ installs: one is Acorn C/C++ 5, in HostFS::$.SoftDev.AcornC5.AcornC/C++. The other is the latest ROOL 31c compiler in HostFS::$.SoftDev.AcornC_ROOL.AcornC/C++.

I’ve started from scratch with a clean check-out, and a clean installation of the C compiler from a ZIP file graciously provided by ROOL earlier today.

The checkout steps are on Linux, into the HostFS directory. The rest is inside RISC OS.

• git clone <a href="https://gitlab.riscosopen.org/Products/All.git">https://gitlab.riscosopen.org/Products/All.git</a> AllWorkDir --recursive
• (cd AllWorkDir; git submodule update --init --remote)
• Switch to RISC OS (in RPCEmu)
• Set Next slot to 7200K in Switcher (19000K free)
• Open $.SoftDev.AcornC_ROOL.AcornC/C++$, run @!SetPaths
• Run AllWorkDir.RiscOS.Apps.!Prepare, then !Perl, then !Builder in the same directory
• Builder – right click icon, drag AllWorkDir.RiscOS to the window, Add, Save.
• Builder – left click icon, set Environment ROOL.IOMD32. Check all boxes except BBE and Install Disc. Click Build.

And again – genyuvtabs has failed to build, with a missing symbol (__assert2) and the same attribute difference.

Digging further into this, it looks like the InstallTools script had somehow installed an old 26-bit version of the libraries from “somewhere”.
Now more concerningly, the Force option is turned off for the library copy. So if you install some old Stubs, they’ll never get updated unless you delete them first.

So I went in and deleted them, re-ran Prepare / InstallTools, and rebuilt, and it worked!

Well it failed with “ROM image overrun”, but that’s fixable. :D

I’m using the “ROOL.IOMD32” environment. It’s a “git clone —recursive” from the “All.git” repository – see below for the full set of commands.

That bit’s OK…

Builder – left click icon, set Environment ROOL.IOMD32. Check all boxes except BBE and Install Disc. Click Build.

…but like I said on Monday you can’t meaningfully build a valid product from All.git. The proper product definitions make branch selections (notably ScrSaver and IIC for IOMD32) which you’ve skipped past by starting from All.git. That’s why the examples in the cheat sheet make you clone a product by name rather than from All.git.

Now more concerningly, the Force option is turned off for the library copy.

That’s intentional – the InstallTools script only operates once regardless of how many times it is run, it doesn’t overwrite because that would disturb your tree. This is so you can keep multiple trees all with known sets of tools, eg. for doing releases.

…but like I said on Monday you can’t meaningfully build a valid product from All.git. The proper product definitions make branch selections (notably ScrSaver and IIC for IOMD32) which you’ve skipped past by starting from All.git. That’s why the examples in the cheat sheet make you clone a product by name rather than from All.git.

Well that’s a derp on my part! I didn’t realise branches were being used in that way (at least initially) … Just after I posted, I switched over to the “IOMDHAL” repository and continued working from there.

That’s intentional – the InstallTools script only operates once regardless of how many times it is run, it doesn’t overwrite because that would disturb your tree. This is so you can keep multiple trees all with known sets of tools, eg. for doing releases.

Fair enough!

I’ll try and figure out why it picked up the Acorn C/C++ 5 stubs when I’d definitely double-clicked the 32-bit SetPaths before running Prepare.
In any case, after deleting the errant Stubs, re-running Prepare, and rebuilding, it’s built fine.

I had a false start where starting the Desktop got me an “undefined instruction at FC129360” error — which in my build was inside WindowManager. That was down to building FPEmulator with only hardware floating-point support: RPCEmu doesn’t emulate the FPA (or the ARM7500fe’s onboard FPU for that matter), and WindowManager seemingly needs FPEmulator to work.

I think at this point I need to push what I have into the Git repositories, and then I can start adding some extra modules (starting with GPIO and NVRAM support so I can turn the video-out on and off) and flash some EPROMs. And after that, figure out how to add files (like a Boot structure) to ResourceFS, or some other kind of ROM FS.

It’s looking good! :)

I’ll try and figure out why it picked up the Acorn C/C++ 5 stubs when I’d definitely double-clicked the 32-bit SetPaths before running Prepare.

That was a bit unexplained, I couldn’t spot any constructs of the form if "somevariable"<>"" then don't set it which would have explained things if your old copy of Acorn C 5 had been seen by the Filer before the ROOL DDE one.

I had a false start where starting the Desktop got me an “undefined instruction at FC129360” […] that was down to building FPEmulator with only hardware floating-point support

Not sure how you managed that. The choice of FPEmulator is governed by the Machine system variable, and the one for IOMD definitely calls out soft+hard variant, and the IOMD ROMs I produce drop straight into RPCEmu. RPCEmu’s very handy as no matter what dodgy change I make I can’t set anything on fire if I mess up.

And after that, figure out how to add files (like a Boot structure) to ResourceFS, or some other kind of ROM FS.

You just need a dummy component (conventionally in RiscOS.Sources.SystemRes) with whatever files you want, then during the resources phase copy them to where builder tells you to. Here that’s RiscOS.Sousrces.Internat.Messages.Resources.ROOL.IOM32.01.UK – everything in there is what ends up in ResourceFS.

> I had a false start where starting the Desktop got me an “undefined instruction at FC129360” […] that was down to building FPEmulator with only hardware floating-point support

Not sure how you managed that. The choice of FPEmulator is governed by the Machine system variable, and the one for IOMD definitely calls out soft+hard variant, and the IOMD ROMs I produce drop straight into RPCEmu. RPCEmu’s very handy as no matter what dodgy change I make I can’t set anything on fire if I mess up.

I’ve copied the env and components files for IOMD as Lazarus and used that machine name, because a lot of the hardware support code is still in there and I’d like to get it going again. The Bush box also has some differences vs. a RISC PC or A7000 (only one Podule slot, 37C669 SuperIO, PAL video out, …), so it probably needs its own machine type definition to handle all of that.

The mistake was — A couple of modules (notably ADFS and FPEmulator) pull in source files named after the Machine system variable. I looked at the various FPEmulator configs and noticed that the STB builds used hardware FP, and did the same for mine. And completely forgot that RPCEmu needed software emulation because it doesn’t emulate the FPA. I went back and changed it to “Both”, i.e. FPU support and emulation support, and it ran okay on RPCEmu.

At the moment I’ve got a build which runs under RPCEmu, but doesn’t boot on the physical hardware. I’ve got Debug enabled for the Kernel, but nothing comes out of the Super I/O serial port. I’ve found the HAL Debug flag and I’m doing a build with that enabled to see if it gives any more insight.

I noticed the working RO3.71 boot code initialises the Super I/O and IRQs differently — some IRQs are remapped and the Super I/O IRQs are active-high — but I don’t know if that’s relevant.

It also behaves a bit oddly under emulation – but this may be down to a corrupted CMOS as I’ve not been able to get delete-power-on to work in RPCEmu. Basically if I configure it not to boot to the desktop (Configure Language 0) it’ll boot to Supervisor then I can do *Desktop to get a desktop. If I *Configure Language 11 (autoboot into the desktop) then I get a grey screen with a cursor.

If I *Configure Language 11 (autoboot into the desktop) then I get a grey screen with a cursor.

It is Language 13 for Desktop in OS5.29 IOMD.

To reset CMOS, having tried 11, I resorted to deleting the cmos.ram file from the host, which is Ubuntu in a VM on a Mac.

It is Language 13 for Desktop in OS5.29.

Indeed. As per documentation
“The module_number is specified by the number returned by *Modules command. Numbers may differ depending on versions of the Operating System, and whether modules have been added or removed.”

Sort of makes you wish it was available as Configure Language Desktop

If I *Configure Language 11 (autoboot into the desktop) then I get a grey screen with a cursor.

This is surely a bug, a wrong number here should not be able stiff the machine.

11 in the IOMD OS5.29 ROM is the Window Manager.

My experience is that erroneously configuring a startup into a module that is not a language is benign and leaves one at a * prompt. All possible options have not been tested but other ‘wrong’ numbers do indeed fail to a * prompt on OS5.29. Also attempting to start up in the Window Manager on OS4.02 goes to a * prompt.

He gets a grey screen with a cursor.
Sounds like the window manager might be trying to start, and failing for some reason?
Are any other modules unplugged?

I looked at the various FPEmulator configs and noticed that the STB builds used hardware FP, and did the same for mine. And completely forgot that RPCEmu needed software emulation because it doesn’t emulate the FPA. I went back and changed it to “Both”, i.e. FPU support and emulation support, and it ran okay on RPCEmu.

Ah right, that makes sense then. The STB builds all used the Cirrus 7500FE so had “proper” hardware FP, Bush internet TV too except that then you can’t try it in RPCEmu as you say if it’s not emulating all the FPA ops.

At the moment I’ve got a build which runs under RPCEmu, but doesn’t boot on the physical hardware. I’ve got Debug enabled for the Kernel, but nothing comes out of the Super I/O serial port. I’ve found the HAL Debug flag and I’m doing a build with that enabled to see if it gives any more insight.

If by “on the physical hardware” you mean “the Bush internet TV” then that doesn’t surprise me. The HAL-ification was done after that, so although there may be a few unused switches hanging round in the code none of it will have been enabled since the early 2000’s and the ‘669 is sufficiently different to the ’665 I doubt it’d work out of the box. All those switches selected on Lazarus in Hdr:Machine will have changed the contemporary Kernel, not the HAL-ified one.

This is surely a bug, a wrong number here should not be able stiff the machine.
11 in the IOMD OS5.29 ROM is the Window Manager.

Mmm, interesting! Desktop is at ROM position 11, but if *Configure Language is keying off the module chain position that needs looking at, because the early keyboard scan means some modules get lifted up the list.

Window Manager does have an entry point, so if entered it’ll try starting a dummy task and sit there, which sounds like what it’s doing: grey screen and presumably the mouse moves around?

This is surely a bug, a wrong number here should not be able stiff the machine.
11 in the IOMD OS5.29 ROM is the Window Manager.

Mmm, interesting! Desktop is at ROM position 11, but if *Configure Language is keying off the module chain position that needs looking at, because the early keyboard scan means some modules get lifted up the list.

Desktop is at Modules position 13.

*Configure Language 13 enters the Desktop

*Configure Language 11 stalls at a grey screen with mouse pointer but no cursor

*modules
No. Position Workspace Name
 ...
 11 FC1122D4 20004394  WindowManager
 12 FC132DDC 2013CD54  TaskManager
 13 FC136E60 00000000  Desktop
 ...
 18 FC1783E4 00000000  ADFSFiler
 19 FC17C960 00000000  BASIC


 *rommodules
No. Position    Module Name             Version Status
 ...
  9 System ROM  WindowManager           5.85    Active
 10 System ROM  TaskManager             1.54    Active
 11 System ROM  Desktop                 2.77    Active
 ...
 17 System ROM  ADFSFiler               1.15    Active
 18 System ROM  BASIC                   1.85    Active

The PRM has this :-

*Configure Language sets the configured module that will be run as an application at power on. The module is specified by its module number, as returned by the *Modules command. You should use that command to check the number you’re configuring, especially if you have added or removed modules. You should also be aware that module numbers may differ between versions of RISC OS.

To confirm that the *Modules position is the one required :-

*Configure Language 19 enters the BASIC V

*Configure Language 18 tries to enter ADFS which errors.

Or is there a larger bug here?

I noticed the working RO3.71 boot code initialises the Super I/O and IRQs differently — some IRQs are remapped and the Super I/O IRQs are active-high — but I don’t know if that’s relevant.

It’s been a very long time, but ISTR the ’665 had traditional semi-fixed IRQs and the ’669 supported ISA PnP. So in the ’665 had IRQs which could be remapped by jumpers in the classic ISA card way and on the ’669 you could go write to it a secret knock and go into a configuration mode where you could remap the interrupts.

(the secret knock was in the datasheet, but I’m not sure if it supported the official ISA PnP standard or just something analogous to it)

I think once everything is set up the serial port should work equivalently – they’re both 16550 clones.

I’m assuming the ARM-side of the interrupts is the same, ie there’s nothing between the SuperIO and the 7500FE? Sometimes CPLDs or similar would be sneaked in to do interrupt management (especially where interrupts are shared, especially on podules), although I’ve never worked with the 7500FE.