ROM build, 2016-12-18, coming unstuck.

On attempting to build a Titanium ROM from today’s, 2016-12-18, source tarball I noted the subsequent c.glue upload to cvs so downloaded that as well. The build didn’t go very well.

XHCIDriver (mixed.RiscOS.Sources.HWSupport.USB.Controllers.XHCIDriver)...
amu -E  rom_link ADDRESS=4229712544 LINKDIR=ADFS::Titan4.$._ROOL.ROOLhi.TitaniumDev.Install.ROOL.Titanium.USB COMPONENT=XHCIDriver TARGET=XHCIDriver 
cc -zM -zps1 -Wp -c -depend !Depend  -DRISCOS -DBRANCH_NHUSB -D_KERNEL -DDISABLE_PACKED -DROM -I^.^.NetBSD,TCPIPLibs:,C: -ff -fah -o o.glue c.glue
Norcroft RISC OS ARM C vsn 5.71 [25 Aug 2014]
"h.glue", line 89: Serious error: Expecting <declarator> or <type> but found 'int'
c.glue: 0 warnings, 0 errors, 1 serious error
AMU: *** exit (1) ***

AMU: *** 'rom_link' not re-made because of errors ***

Error running make rom_link on module 'XHCIDriver'.
Fatal error running make rom_link on module 'XHCIDriver'.
Batched errors...
Error running make rom_link on module 'XHCIDriver'.

Line 88 in h.glue does not look quite right to me, or necessary?, so I commented it out and the build then completed. And started up as a softload on the Titanium.

/* Little helpers */
int ffs(int);
/* int min(int, int); */
const char *intl_lookup(const char *);

It should be perfectly clear by now that I don’t know much about C.

Line 88 in h.glue does not look quite right to me, or necessary?

It (was) right since function prototypes in C don’t need to have names after the types, but the change to usb_port.h yesterday ended up with a macro also called “min” which would have expanded that line to

int ((int)>(int)?(int):(int));

It should be perfectly clear by now that I don’t know much about C.

I don’t even know anything about ROM-building as well, but perhaps here might be where I can ask about the build on the RPi download page.

This has been stuck for some time with the supposed build-date changing occasionally, but the image remains the same size and the ROM itself displays the same date – 5.23 (26-Oct 16).

Today’s offering has increased in size by 4K, but still bears the date 26-Oct-16 in its “About” box. Is it the same, or has it changed? I’m having difficulty getting my head round what’s actually going on with these Beta RPi ROM development builds.

Can anyone elucidate in simple terms?

Today’s offering has increased in size by 4K, but still bears the date 26-Oct-16 in its “About” box.

In my view this really should be a new topic, it appears to be a significant error in its own right that has nothing at all to do with building ROMs.

Just to confirm that today’s beta Pi ROM correctly reports itself as (18-Dec-16).

On my Pi the firmware and ROM are on a single partition 4GB SD card, RISC OS is elsewhere. No chance of the Fat32 partition and the Loader directory on an RCxx installation somehow being two separate things. Now that’s what I call guesswork.

In my view this really should be a new topic, it appears to be a significant error in its own right that has nothing at all to do with building ROMs.

OK – will do that if necessary,

Just to confirm that today’s beta Pi ROM correctly reports itself as (18-Dec-16).

Do you mean one you have built yourself, or the one from the download page at https://www.riscosopen.org/zipfiles/platform/raspberry-pi/BCM2835Dev.5.23.zip – here that reports itself as I suggested. If the former I will start a new topic; if the latter, seek psychiatric intervention!

Do you mean one you have built yourself, or the one from the download page at https://www.riscosopen.org/zipfiles/platform/raspberry-pi/BCM2835Dev.5.23.zip

That would be irrelevant, they would have the same build date. It was in fact a download, there is no need to build something that ROOL has already provided. The Titanium ROM was built in this instance because ROOL’s build had failed but the correction had been uploaded.

What seems to be going on here is that the newer Pi ROM downloads are being installed somewhere onto an SD card but are then not being loaded into the Pi, which is somehow seeing an older version. I assume this is an RCxx dual partition installation but that is a guess, that information is not given. As good a way as any other of lousing up an RCxx card is to delete !Boot.Loader then try to recreate it. The clever bit about RCxx is the way that !Boot.Loader maps to the Fat firmware partition. The contents of !Boot.Loader can be altered but under no circumstance can the directory itself be interfered with.

To be as clear as I can be, there is nothing wrong here with the beta Pi ROMs.

HTH.

What seems to be going on here is that the newer Pi ROM downloads are being installed somewhere onto an SD card but are then not being loaded into the Pi, which is somehow seeing an older version.

Well done – exactly so! Somehow my Loader partition has got mixed up with a copy, and presumably the location on disc swapped, so the one the Pi is using is not the one in Boot:

Thank you – it’s amazing how many files called Loader there can be on a HD! A very popular “filename”!

Apologies for hi-jacking your topic, and thanks again for your help!

The psychiatric intervention may not, after all, be necessary at this time!

Edit:

PS SystemDisc just sorted it out! I shall now delete the copies and only keep them on a different disc!