Identifying ROM build

With the changes happening thick and fast !!, would it be an idea to append a build version to the 5.17 in the switcher info box ?
I have just built a test ROM with 5.17a as the version so it can be done.
This may help with bug tracking, and also when reporting devices that work.
I’m sure the ROOL staff know where this is set, but for us mortals, OMAP3Dev.castle.RiscOS.Sources.Kernel.Version (with the new layout of the build tree).
Just using one letter will not be enough, as the next official release may be ages ahead, so maybe three letters ? (I was thinking of avoiding numbers, as that may look confusing in the display).

It might make sense to change the switcher so that (for odd ROM version numbers?) it displays the ROM build date (available via OS_ReadSysInfo 9, IIRC).

That would be very useful, I should think.

If the date change is the way to go, that’s simple to achieve in the file I mentioned. Just move the Date SETS Module_Date line to outside the compile switch brace.

Test build shows that works.

If you’re talking about the “Version” file in the kernel sources, I think you’ll find that would mean the date reflected whenever the kernel sources were most recently committed, which is something quite different from the build date: for example, it tells you nothing about any other modules which may have changed.

The reason why there’s a build switch there is that all the flavours of RISC OS-NC and RISC OS-STB actually had the UtilityModule report the kernel’s version number (which has been stationary at 5.35 for some years now), whereas for desktop builds, it has traditionally had a version which matches that of the OS as a whole, which was always more of a marketing decision than a reflection of actually how much had changed in the kernel. The embedded versions of RISC OS used version numbers which didn’t follow the x.xx pattern, which is presumably why they had this change made.

While I remember about this… A while a go I had a quick look at hooking up the build date, and found OS_ReadSysInfo 9 returns the kernel build date, not the ROM build date. This obviously won’t update very often if the same source tree is used to do lots of builds without any kernel updates inbetween. So I think the best thing to do would be to update romlinker to store the build date at the end of the ROM image (same as it does with the signature/checksum stuff), and make sure that OS_ReadSysInfo 9 uses that. But I haven’t yet remembered to propose these changes to ROOL in an email.

Also, thinking about it, it would probably make sense for us to use the pre-existing ROM signature field to store the type of ROM, e.g. IOMD, Tungsten, OMAP3, etc. This should allow the softload tool to perform a basic sanity check that someone isn’t trying to load the wrong ROM image. But this approach might not work so well since the tool will still have to cope with existing ROM images which don’t have a signature set (and I’ve got no idea when the signature field was introduced, or what values it used to be set to in the past).

Anyway, now that I’ve remembered about this I’ll (hopefully) remember to email ROOL about it later tonight!

update romlinker to store the build date

That seems quite sensible. I think I’d be against something that changes the module contents depending on the build date (because you’d get two different binaries without changing the code).
Extending that thinking a bit, do you even need a date? Is the CRC unique enough?
So the fully qualified version would be 5.68-F0-34-07-22 for example with 5.68 and a CRC of F0340722.

Extending that thinking a bit, do you even need a date? Is the CRC unique enough?

The main point of adding the date is to allow it to be used to identify how old the ROM was, either for bug tracking purposes or just so that users can easily tell if they’re running the latest build or not.

Displaying the CRC could be useful if we wanted to get really anal about which builds people are using (especially if ROOL kept a history of what component versions went into each ROM build), but for most purposes just knowing the build date will be enough.

which builds people are using

Ah, humans. Yes, maybe a date is simpler (even if it’s encoded in the ROM as a 5 byte centiseconds).

What is the criterion for moving to an even numbered build (5.18) and then having development versions at 5.19? Launch of the ARMini seemed to me a sensible time to do this.

criterion

"From now on, even numbered versions of RISC OS will be the official, tested releases. Odd numbered versions will be development works in progress."

Launch of the ARMini seemed to me a sensible time to do this.

That’s a very good point. Maybe Andrew Rawnsley has had some discussions along these lines. AsloAlso (if Jeffrey still feels this way): "[…] Although I generally prefer to work on new features rather than fixing bugs, I’d gladly switch over to full-time bug-fixing once the decision is made that a stable release is needed.".

This is a good point. Frustratingly, the latest build includes some changes which one might consider “next release” as opposed to “current release” eg. the updated filer_action. Whilst I haven’t seen any bugs in the current release, in hindsight it might have been better to keep new features out of 5.17 (or called such a release 5.18) and then drafted the new stuff into 5.19.

However, my feeling right now is that since the pen is open, it is too late to bolt the door. We should probably work towards a stable version of what we have, and do a formal 5.20 (nice round number) release over the summer.

This would fit with out schedules here. We’re still working on our roll-out of pre-orders. I’m hoping this will finish by the end of August.

At that point, we should be in a position to deliver a big update to everyone. Hopefully Dave Higton’s micro-sd updater routines will also be ready by then, so that we can do an in-place update and deliver a really good user experience with said OS release.

Thoughts welcomed…

Aslo (if Jeffrey still feels this way): “[…] Although I generally prefer to work on new features rather than fixing bugs, I’d gladly switch over to full-time bug-fixing once the decision is made that a stable release is needed.”.

Yeah, I still feel that way. Although I’ve just spent the last 10 or so hours tracking down null pointer accesses, so it’s not like I’m not fixing bugs at the moment!

Thoughts welcomed…

For the next stable release (whenever it will be) it would be nice to have the Cortex kernel branch changes merged back into the HAL branch. This will help keep the two branches from diverging too much, and will keep the HAL branch as the stable branch and the Cortex branch as the unstable/development branch. And it would be particularly useful if it could be done in the next week or two so that I can check in all my zero page protection kernel changes without worrying about breaking the kernel (and before someone else makes some kernel changes and I’m left with a massive merge conflict!)

it is too late to bolt the door

Does anyone have any idea how much of an eye Castle keeps on developments?

What is the criterion for moving to an even numbered build?

The idea was that the even-numbered releases, of the Iyonix ROMs at least, would have received a certain of level of testing by Castle, to give end-users a certain level of confidence in them. RISC OS 5.16 was rushed through to fix the Y2K01 bug if you remember – the lack of any stable releases since then just means that nobody has taken the initiative to declare a code freeze and arrange with Castle to do any more testing. It would be good if in future the OMAP3 ROMs could have simultaneous stable releases – perhaps R-Comp would be willing and able to sign off on stable OMAP3 ROMs in a similar way that Castle can for Iyonix ROMs?

I’d be quite happy to fulfil that role, Ben :)

Over the weekend I checked in some changes to romlinker and the kernel to sort out the way the build dates are handled. Briefly:

• OS_ReadSysInfo 9,2 will now return the date/time the ROM image was created instead of just the date/time the kernel was last built
• For odd-numbered (i.e. development) OS versions, the UtilityModule date will now be the date the kernel sources were last changed instead of the hardcoded date it was displaying before.
• For odd-numbered OS versions, *FX 0 / OS_Byte 0 will now repot the date that the ROM image was created (instead of the same hardcoded date that the UtilityModule was reporting).
• Since the switcher uses OS_Byte 0, that means the switcher will now display the correct date also
• For most of the above to work, I added some extra functionality to romlinker to add the build date to the ROM footer. I also added a new “noimagesize” option to disable the mysterious code that overwrites locations &60-&63 with the ROM image size. See this wiki page for more info about the new ROM footer format and how to use the noimagesize option.

The OMAP ROM has already been rebuilt with the date/time changes. The next time the Iyonix & IOMD ROMs get rebuilt they should start using the new system too.