Daily Pi ROM

I notice that the daily Pi rom is still 3 June although some changes were checked in on 10 June and that the lastest Pi tarball fails to compile.

It hangs on ROMFonts (sed) but I have DDE30b. However it also produces an error in other places:

it throws an error – STM with SP in the register list – in library export socklib, and then fails in the HAL BCM2835.hdr can’t be opened.

I notice that the daily Pi rom is still 3 June although some changes were checked in on 10 June

There was a build failure yesterday.

the lastest Pi tarball fails to compile. … It hangs on ROMFonts (sed) but I have DDE30b.

A build from git yesterday, which did have HAL_BCM2835 1.01, with DDE31b was fine.

A build from today’s source code tarball is also fine and up to date.

There is a Pi ROM with the 10 June changes here.

As a bonus it is retro fitted with Menu 0.40, avoiding the broken Menu 0.41.

Thank you, David. That brings me back to being able to test and provide feedback.

An 8GB aware PiROM was here. It was later removed after a serious issue was found.

It is from today’s source code tarball but with Menu 0.40.

This ROM will reveal the full 8GB of RAM when present and should also work on smaller Pi’s. Prudently, regard this as a beta of a beta. OS5.29 is beta and Long Descriptors is also beta. That said it is stable here on both an 8GB and a 2GB RPi4B.

There is no change to the source, all that is needed is to set LongDesc to TRUE in Kernel.hdr.Options

A known issue is that gcc10 built code only runs in the first 4GB and that includes Iris. If you have been working too hard and filled the bottom 4GB then Iris will fail to start. Iris is fine in the lower 4GB. There may be a possible work around for that.

As I understand it, it is intended to formally introduce this in OS5.31, so immediate support may not be on offer.

ROOL’s roadmap is here and the 8GB brain work out is here.

Take this as a cheeky preview of what could be to come.

7841876K Wow!
8060928K :)

A known issue is that gcc10 built code only runs in the first 4GB and that includes Iris. If you have been working too hard and filled the bottom 4GB then Iris will fail to start. Iris is fine in the lower 4GB. There may be a possible work around for that.

Hopefully soon, as that’s the sort of nonsense we had to put up with on the Kinetic, having to ensure certain things were pre-loaded in to one type of memory or another.

There is a Pi ROM with the 10 June changes here.

As a bonus it is retro fitted with Menu 0.40, avoiding the broken Menu 0.41.

Many thanks for this. Does anyone have a CM4 Lite with WiFi to test whether the SD card appears as SDFS::0 or SDFS::4 please.

It shows up as SDFS::0 here on a CM4 Lite, 2GB with WiFi, and the above ROM.

The daily roms now (as of 14 Jun 2023) include the fixes to run a CM4 with the Pcie slot empty.

An 8GB aware PiROM is here

The 8GB Pi ROM had been stable for quite a while but a significant issue has now made itself known, an abort on data transfer in the Kernel followed by a terminal crash.

*where fc014A80
Address &FC014A80 is at offset &00014A80 in the Kernel
*

Further development of the 8GB is for OS5.31, the priority for now is getting OS5.30 released. So for now it is back to 4GB ROMs and the 8GB test download is removed.

It shows up as SDFS::0 here on a CM4 Lite, 2GB with WiFi, and the above ROM.

@andym
ScreenHelp version 1.74 should now show this as CM4 Lite with WiFi. An extended revision code on the CM4 flags whether eMMc and/or Wifi are fitted.

There is a Pi ROM with the 10 June changes here.

Thank you. On my Pi 400 I was finding shimmering (and ineffectual) menus with CLFiler as well as with FTPc. David Pitt’s 5.29 (12-Jun-2023) ‘beta of a beta’ with module Menu 0.40 restores correct working.

David Pitt’s 5.29 (12-Jun-2023) ‘beta of a beta’ with module Menu 0.40 restores correct working.

ROOL sent me a better way of ducking Menu 0.41. It installs in PreDesk and softloads Menu 0.40. The daily betas can then be used as is without any need to build special ROMs.

This is only required for OS5.29 beta ROMs after 18 Jan 23 which is when Menu 0.41 was released. It is not required for OS5.30/1 release candidates, they are already reverted to Menu 0.40.

When Menu 0.42 arrives it can be removed, but it is benign, it does nothing in that circumstance.

This is the Obey file.

| Downgrade Menu until a fix (assumed in 0.42) is available
Set Menu$Replace 0
RMEnsure Menu 0.42 Set Menu$Replace 1
If <Menu$Replace> Then RMLoad <Obey$Dir>.Menu

Download.

Oops, a minor take 2 was required. I had wrapped the installation to Choices in a dummy !Boot for use with the Boot merge tool. But Choices can now can be external to !Boot, but the merge tool does not know about that. Obey files are provided that find Choices wherever it is and hidden or not.

Toolbox Menu module

(O.T.-ish. And then I got caught out some more by the hidden !Boot thing, how to install a Pi ROM in (hidden) Loader. The Pi ROM does not have to be in !Boot either. Another Obey file is called for.)

Thank you, David, for sharing the workaround. ;) I’m holding the popcorn avidly watching this aspect of the thread evolve. I can’t help but be curious as to why this particular version of the Menu module still exists in the build pipeline- I’m not looking at the bounty claimant for an answer or anyone else- it just seems strange that it persists, needs a workaround, and is not withdrawn.

I can’t help but be curious as to why this particular version of the Menu module still exists in the build pipeline

It’s not in the release candidate, so it’s just in the nightly builds – which are described as “work in progress”. That seems fair: no-one says that the nightly builds will work.

As for why it hasn’t been removed, if it has been merged into the main branch then you’re looking at having to back specific commits out and then re-introduce them somehow later on (and store them somewhere in between times). That’s possible, but if there’s dialogue with the bounty claimant around fixing the issue then it’s probably a lot cleaner to leave the code in place and merge the fix in when it’s ready. And since the nightly builds are a work in progress, that doesn’t seem too unreasonable.

In the end, I’m happy to go with whatever is easiest for the ROOL folk who are doing all of this for us for free in their spare time… :-)

And since the nightly builds are a work in progress, that doesn’t seem too unreasonable.

No. No! NO!

<stomp> <stomp> <stomp> <stomp> <slam>

:p

Rick, I was expecting an emoticon, or similar, for at least a sub-orbital teddy. :)

I can’t help but be curious as to why this particular version of the Menu module still exists in the build pipeline

Me too. It has been widely proved to be defective, to the extent that it needs a work-round to permit other apps to work correctly.

As such, it gets in the way of testing nightly builds.

It should be backed out until a replacement is proposed for testing.

It should be backed out until a replacement is proposed for testing.

I guess that you and Andrew are offering to actively assist with managing the RISC OS codebase? Then again, it’s always easy to say what other people should be doing. :-)

More seriously, I’d be interested to know how you would go about doing what you suggest in a way that doesn’t create extra work for the ROOL folk. You can’t just rewrite history, as that’s not great for anyone with cloned copies of the repo. So I think you’re left with taking copies of the changes, backing them out, then re-creating a new merge request with the changes back in again, waiting for the fix to be forthcoming, getting that into the merge request, and then testing. Plus, I suspect, a double-bump of the version number (1.42 is the reverted version, as it’s not the same codebase as 1.40, then 1.43 as the second attempt). The history would be interesting to follow, too…

Which is why I suspect that they might have been waiting for the fix, so that it could have been merged in sequence to create 1.42.

Then again, I’m not a Git expert, so I might have missed an easy solution.

The “correct” way to do this, of course, would have been to test everything before the merge request was merged into master for the nightly builds. That’s easy to do if you have a team of full-time software testers whose job it is to build and test all pending merge requests, but a lot of work for people otherwise.

Edit I guess they could peg the version of the submodule that’s pulled in for the build, though. That would probably work, but could confuse people. I think – it’s been a while since I’ve used submodules in Git, and haven’t checked that they’re even what ROOL are doing with the repos.

Steve, I think you’re inventing an unnecessarily complicated sequence of actions.

Whoever introduced the changesfor version 0.41 has the source code for 0.41, so it doesn’t seem to me to need any additional place to store it. Just back 0.41 out. Revert to its predecessor, 0.40.

When the replacement is ready, the version should be changed from 0.40 to 0.42. Change of version number (and date) is a standard part of introduction of any new version. It’s manual, so any number can be chosen, and there is no difficulty in skipping over the number of an already-introduced-and-known-to-be-faulty version.

I have contributed (in a very small way) to the RISC OS codebase, but this one is best handled by the author of the changes that gave us 0.41.

Just in case anyone should get a wrong idea, I’m not playing holier-than-thou. I too have written defective code before. Many times. We all do it, and we have to manage it.

I’m one of the people very much hoping for a RISC OS git client app, because, although I’ve used two version control systems in the past, I really don’t understand git.

ROOL sent me a better way of ducking Menu 0.41. It installs in PreDesk and softloads Menu 0.40.

As the module Menu is not crucial to the start up of RISC OS, having 0.40 replace it at PreDesk is a good solution that should allow testing of daily roms on the Raspberry Pi until RC4 appears for the Pi (which will have Menu 0.40) later this week/month. The Pi has probably the largest user base and testing the release candidate for this is quite important. It is possible that latest revisions of Pi model 4 may have a caveat (due to the new PHY) but we don’t want to delay testing…

latest revisions of Pi model 4 may have a caveat (due to the new PHY)

I’ve now got the Micrel PHY working nicely, the first (minor) part of that is already queued. The slight downside is I’ve broken the original Broadcom PHY. Seems a few worms escaped when the lid was briefly off the can…

Thanks, David et al. I’ve kicked the daily build tyres, and the menu workaround seems fine following a reboot. :)