Allwinner H3

The Linux port is my “daily driver” version of RO. One thing I have noticed is that it is slow on the Pineboook compared to the Orange Pi PC and PC2. Still quick, but slower. I haven’t bothered to look but I wonder if the Pinebook could have an internal USB hub.

I’m perplexed as to why booting broke again. Kind of a nuisance because sometimes it can be days before I’m able to test a build. An idea that I never bothered to get around to trying is to use an esp8266 attached to my “dev board” and the network with a couple of open ports. One for serial and one for commands and such

I tried re-adding FPASC. Same old error.

FPEmulator (mixed.RiscOS.Sources.HWSupport.FPASC.riscos)...
amu -E  install_rom INSTDIR=IXFS:$.dev.fd.5.HardDisc4.myStuff.RO_Rebase.RO_AWH3Dev.RISC_OS_Dev.Install.ROOL.AWH3.HWSupport COMPONENT=FPEmulator TARGET=FPEmulator FPE_APCS=3/32bit FPEANCHOR=High
AMU: Don't know how to make '^.RISCOS'
AMU: *** 'install_rom' not re-made because of errors ***

Error running make install_rom on module 'FPEmulator'.
Fatal error running make install_rom on module 'FPEmulator'.
Batched errors...
Error running make install_rom on module 'FPEmulator'.

I just don’t know what it wants from me!

AMU: Don’t know how to make ‘^.RISCOS’

What are you building under? That error sounds like it’s either in the wrong directory when it tries to compile, or the filesystem doesn’t understand that ^ means the directory above the current.

I just don’t know what it wants from me!

As a novice user of the DDE and !Builder etc. I just let it tell me verbosely, but it is telling you that it can’t make RISCOS and the last line is telling you the specific component it can’t build is ‘FPEmulator’ – there may be more down the line but that was where it fell over and failed.
If it can’t build one component the whole build stops. All the preceding components will have been built and be sitting in the individual directories waiting to be added to the overall ROM image.

Personally I’d drop into the FPEmulator directory of the build i.e. mixed.RiscOS.Sources.HWSupport.FPASC.riscos and run the make file there to see what specifically it complains about.

In my case it would be a long time staring and puzzling and then I’d kick myself.

Edit: In the case of trying to build a complete IOMD image the reason I kick myself is that the current source requires a version of DDE slightly newer than I have (24) because of this:

#if CMHG_VERSION < 543
#error "Need working help: keyword support in CMHG"
#endif

in the code for Internet. So as it stands I can build most of the ROM but not that bit and the ROM build fails.
Kick, time to get off ar** and purchase current DDE…

Like C, it’s usually best to start at the top of the gibberish and wade downwards.

It cannot find something called “RISCOS” which is specified as being in the parent directory (the ^.). Because of this, FPEmulator cannot be built.

What is this missing file?

Side note : something subtle has changed in objasm. I’m finding a lot of projects that built for years failing to build with weird paths not found. If the makefile contains “-desktop”, take that out. It’s broken…

in the code for Internet.

Temporary fix – remove the message and the help reference in the cmhg description. ;-)

But, yes, newer DDE is probably a better bet in the long run… How old is your current version?

Temporary fix – remove the message and the help reference in the cmhg description. ;-)

Or carry on, until I do the purchase, with the current small work doing little stand-alone¹ builds of other modules with minor modifications.

How old is your current version?

I did say 24, and that has cmhg version 342 sitting in it. So, that’s erm, about 6 years old.

¹ Entertainment value in that specific combination of letters without the hyphen – there’s an add-in for Firefox (LanguagePlus) that checks online. It dislikes standalone and offers stand alone which it also dislikes (but less so) and offers stand-alone.

Just a quick post in case I forget later. Computer time is somewhat limited right now.

re: FPEmulator.
Currently using RO Linux, and I want to say ext4 via IXFS, but I don’t have it handy right now.

The posted result was after I grabbed a fresh FPASC (or whatever it is) from a source tarball to help eliminate corruption.
When I just have it set to -type EXP in the components file, all 118 other modules currently active build without issue.

Last night I had a quick look in the makefile for FPASC and saw mention of ^.RISCOS in the dynamic dependencies.
Although I doubted it’d work, I tried a symlink of RISCOS to the directory riscos in FPASC. As expected, no difference.

Unfortunately I don’t have access to anything running RO natively right now. I can fix that in the short term if someone can point me in the direction of how to run the VNC server at boot so I can have a headless setup stashed away. I tried search but it didn’t yield the results I was hoping for.

e: some of fpasc may be missing from GitLab right now. I have to check via the web interface.
e again: And my heart sinks. Something isn’t right there. Although I did directly add FPASC to my working copy so it should’t be that.

I got VNC sorted and have the RPi Zero running headless.

Although it’s a very slightly older version of the RO source on the Zero it’s only marginally so. FPASC builds on the Pi Zero wwith a FileCore formatted USB drive without issue.
The question is why does only FPASC break during build on a different FS. I still suspect it has to do with case sensitivity.

I was going to compile your sources to see what was happening unfortunately the zip download loses all filetyping so that wasn’t possible.

Colin, this is from GitLab, right?
I haven’t found a convenient way of preserving file types yet. The best method I have is to utilise Sunfish and RO Linux’s comma file typing. So any pushes I make are using the Linux Git. This would probably leave three methods to get the code usable

1: Download with Linux and access the files over network via Sunfish.

2: Download with Linux and access it with the RO Linux port.

3: Download with whatever and use the renaming utility as outlined in the RO Linux port.

I have given up on using RO SVN because of the atrocities it commits to the kernel part of the source tree. Hence my mini rant in wish list (?) where I posted a kernel source that I had rearranged to be more fs translation friendly.

It’s from github – used your earlier link.

You could just upload a zip file

With respect to the FPEmulator failure I have encountered the same problem but using Tmpfs and/or Btrfs instead of Ext4. I work around it using this change. I have not found the cause, but it is not restricted to a specific Linux filesystem.

The file in question is a header file exported by the kernel.

Huh. That’s odd. Totally believable though. I know I had to explicitly add Hdr: somewhere at some point because the build went a bit wobbly without it.
Thanks for that! I can go back to using RO Linux for building instead of a Pi Zero via VNC.

I altered my old Orange Pi “dev board” to have a jumper so instead of a pushbutton to kill power, it can take input from another source to control the relay. I knocked up a couple of short programs to control a GPIO pin on my RPi Zero to switch the Orange Pi PC on and off.
I’m currently still using the headless VNC setup. Still no sign of the Vonets adapter. Had to fix an issue with Armbian yesterday. Had the same issue on other things before. Boot partition filled up during a kernel update and it couldn’t complete. So I haven’t tried the change for FPEmulator on Armbian yet.

At some point over the last coupld of weeks the dreaded boot locking bug crept in again somehow. To my knowledge I didn’t even touch the code that early on in boot during that period. Very frustrating.

It appears to die Pre MMU. Last thing it displays is “get_end_of_ram returns: 80000000”. I know that’s just a hardcoded function. Time to get verbose again I guess. Work out where it’s getting stuck. My gut says ROM relocation or AddRAM is at fault.

I took the September-ish HAL, fiddled it a bit and got it to boot. I’m slowly but surely re-introducing some of the code, with a few minor modifications I wish I’d done first time round. What I find interesting is it’s no longer running !Boot or reading the USB drive at boot any more. Perhaps it got corrupted with my initial attempts of controlling the power with a Pi GPIO pin. It was just doing a single pulse then rebooting the RPi. I sorted that though.

When I get a chance I’ll have to do some fiddling to upload the current HAL. I did save the pre-reversion hal at least.

I renamed the HAL and uploaded the version I’m working on based off older code to GitLab.
For some reason the “new” version which I swapped out would lock during boot.
The current version boots, but doesn’t seem to be able to show the contents of the FileCore formatted USB stick.

The really peculiar thing about that is the HAL from the older version of the source which I based this version off does show the contents of the USB drive. The only thing I can think of is the removal of the stub VideoInHAL device. But that doesn’t make a whole lot of sense to me.

Like aching joints on a cold, damp day a build issue flared back up.

On the bright side it shows me that the HAL causing filesystem access issues was a red herring.

RAMFSFiler (apache.RiscOS.Sources.FileSys.RAMFS.RAMFSFiler)...
amu -E  -k rom COMPONENT=RAMFSFiler TARGET=RAMFSFiler
do mkdir -p o.CortexA7
do mkdir -p rm.CortexA7
create o._dirs
objasm -depend !Depend    -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"CortexA7\"" -pd "UserIF SETS$
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: File "Hdr:ShareD" could not be opened
Error: Bad GET or INCLUDE at line 80 in file s.RAMFSFiler
   80 00000000         GET     Hdr:ShareD
Assembly terminated:
2 Errors, 0 Warnings
AMU: *** exit (1) ***

SCSIFiler (apache.RiscOS.Sources.FileSys.ADFS.ADFSFiler)...
amu -E  -k rom COMPONENT=SCSIFiler TARGET=SCSIFiler ASFLAGS="-PD \"SCSI SETL {TRUE}\"" TEMPLATES=yes
do mkdir -p o.CortexA7
do mkdir -p rm.CortexA7
create o._dirs
objasm -PD "SCSI SETL {TRUE}" -depend !Depend    -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"Corte$
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: File "Hdr:ShareD" could not be opened
Error: Bad GET or INCLUDE at line 225 in file s.ADFSFiler
  225 00000000         GET     Hdr:ShareD
Assembly terminated:
2 Errors, 0 Warnings
AMU: *** exit (1) ***

Not the first time I’ve had this stupid problem. Unfortunately I can’t remember how I fixed it last time.
I only found it by going through the logs. The build phases still complete successfully, just minus the broken modules.

Does anyone know offhand the fix to this irritating error?

Did you delete your “Export” folder? Although most of the contents is populated by the “export” build phases, there’s a skeleton version of the folder in CVS which contains some files which don’t get exported by other components – including the ShareD header.

Specifically, I think the skeleton Export folder in CVS is only used to hold files which belong to closed-source OS components.

Did you delete your “Export” folder?

No. I haven’t done any of that sort of thing until I rebased to a recent tree. I’m actually have /apache/RiscOS/Export/APCS-32/Hdr/Interface/ShareD open right in front of me. It was the only copy of the file that a search yielded
It occurs to me that the Hdr subdirectory is back a level. Is this an issue? Probably not. It is kind of strange though

e: Fixed it. Had to manually copy it from apache/blahblah/Interface/ShareD to Export/blahblah/Interface/ShareD

Not sure what went wrong initially, but it builds now.

e: Fixed it. Had to manually copy it from apache/blahblah/Interface/ShareD to Export/blahblah/Interface/ShareD

In that case, it sounds like you forgot to run the Prepare script which copies the template apache.Export folder to the root of the build tree (which is the location actually used by the build system).

The problem would have been much further spread than export errors in two modules if I hadn’t run the prepare script. I’m going to put it down to cosmic radiation because why not. Thanks for pointing me in the right direction.

I haven’t tested the image yet. I went to do it yesterday and realised a little too late that I borrowed the OPiPCs ethernet cable for the OPi3.
I think I said but it’s all set up so I can code, build and test remotely.

Tested. It has fs access again.
I’m seeing some modules fall over during start up but nothing which is particularly surprising.

e: On the notebook again. Far less tedious.
The last couple of builds have been done using a rather odd setup. I’m using the Orange Pi 3 running Debian Jessie and a legacy BSP kernel to run the RO Linux port. RO linux is running without its framebuffer display program. It is running with network connectivity and the RO VNCServer program running.

The trouble is I can’t leave it set up, so I keep needing to unplug it and put it away.

This morning I cobbled together a rough script to blindly rsync directories and files that I’ve manually added to a second, clean tree for uploading to GitLab.

I made the beginning of a beginning on a video driver. I’ve a couple of much larger bare metal and stand alone RO programs locally which I wrote to play with the hardware. The goal with the video driver currently is just to have it build and have enough written that it’ll look like a functional device to the OS.