Today's Pi ROM image broken :-(

Hi,

Not had chance to do anything EDID-related last night, but thought I’d install the new OS image before work on my Pi (in preparation for working on it this weekend).

Unfortunately I think today’s Pi ROM image is broken :-(. The Pi doesn’t seem to Boot. Changing back to one from 24/12/13 seems fine.

EDIT: oops – this was meant to be in ‘Bugs’. Which is why you shouldn’t browse the site from an iPhone – can’t see very much at a time! Sorry!

Try messing with your overscan settings in the config.txt – it looks like there’s something odd going on with my recent changes (https://www.riscosopen.org/forum/forums/5/topics/2308).

I thought That issue seemed to affect 15 December. I am using 24th December without problems. Today’s ROM however I get no change in the Ethernet lights so I think it has failed to boot entirely rather than just had a display issue.

Will try to look again later but because of the ‘ambiguous disc name’ issue (mirrored SD cards with the same name can’t be used in the same drive) debugging borked ROMs (or messing with Firmware settings) is a bit of a PITA.

From my tangles with ‘ambiguous disc name’ and floppy discs in ADFFS, using Dismount from the Filer works. It’s the only dismount method that works, dismount via *DISMOUNT and Service_DiscDismounted seems to simply unmount the drive and don’t clear the cached entry. I’ve no idea if it works on SD though.

I keep meaning to look at the source to see what it does so I can replicate the behaviour in ADFFS.

EDIT: Correction, it’s Dismount from the Filer that works, not *DISMOUNT, have now corrected the above text.

Assuming the thread title to be a day old then yesterdays ROM (02-Jan-14) is working here on two NOOBS cards. That ROM did stop an updated rc11 card but on the other hand restoring the ROM on that card to 24-Dec-13 has not revived it.

CONFIG.TXT is :-

disable_overscan=1
hdmi_drive=2
fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

Stop Press. I have just revived the ex-rc11 single installation card with a ROM dated 30-Oct-13.

And the Filer Menu dismount does avoid the ambiguous file name thing and does enable editing Boot.Loader on a single OS rc11 type card.

David: Yes – my config.txt settings match these.

Will give it a week or two – watch and see if any issues, then try again. Otherwise I’ll waste my time messing with the setup rather than actually doing useful things :-(.

Good news, today’s ROM (04 Jan 2014) does boot on both a NOOBS card and a single OS rc11 card.

Good news, today’s ROM (04 Jan 2014) does boot on both a NOOBS card and a single OS rc11 card.

That is strange as according to: https://www.riscosopen.org/viewer/revisions no code changes have been made between the two ROM images!

That is strange

It’s strange right enough. Today I can downgrade to the ROM of 02 Jan 14 and the ex-rc11 card boots, yesterday updating to the same 02 Jan 14 ROM and it didn’t boot!!!

Hmm!

I can agree with David: just tried today’s ROM image and it worked fine. Maybe the build failed in some way yesterday?

Maybe the build failed in some way yesterday?

Sounds quite plausible but I thought that a build only takes place if there are any code changes. Two possibilities:
1. I’m wrong
2. The overnight change: “Resync with allocations database” is enough to trigger a build
3. I really don’t understand things
4. I can’t count!

Two possibilities:
…
4. I can’t count!

This isn’t a Spanish Inquisition…

“Resync with allocations database” is enough to trigger a build

Any change in the source tree is likely to trigger a new build; and the allocations database resync means that one or more of the central header files will probably have been modified. And nearly every component has dependencies upon at least some of those header files.

I’d have to look to confirm this, but I think the autobuilder notes whether the “cvs checkout” operation for the build tree results in any changes and if it does, then a new build is started.

I’d have to look to confirm this, but I think the autobuilder notes whether the “cvs checkout” operation for the build tree results in any changes and if it does, then a new build is started.

Correct. Before starting off a build it diffs the entire RPCEmu folder (RPCEmu binary, IOMD ROM image, RISC OS sources, C compiler, etc.) against what was used for the previous build to see if anything’s changed.

IIRC it only updates the “previous build” folder if the build succeeds, so that way any unexpected failures (power outages, intermittent compiler bugs) will cause it to keep trying until it succeeds. Unfortunately it also means it’ll keep trying in the presence of genuine build errors, but usually we fix those pretty quickly!