New Beagle ROM 2010-04-13

I see there’s a new Beagle ROM this morning. What changes does this include?

I can’t see a change log anywhere; if I should be able to please point me at it! The Readme files in the archive are not up to date so they don’t contain the information I’m looking for.

All being well I’ll be trying out the new ROM live at the SAUG meeting tonight.

There’s the revision viewer here, but that only lets you see the 20 most recent changes.

I can’t remember – did ROOL upload a new build after they recompiled the Squash/Resolver/ShareFS binary blobs in early March? If so, then the changes are mainly just bug fixing and adding the NIC setup code to the HAL. If not, then this is probably the first ROOL build to include the new video driver, since it looks like that was only added at the end of February.

There’s no mention in the change log of making SCSIFS the default filing system. There is a mention of a change to ShareFS for ARMv7 compatibility, but that’s dated March 4th so should have been in the March 18th build.

... or was the March 18th build a private one?

There’s no mention in the change log of making SCSIFS the default filing system.

Probably because it hasn’t been done yet :)

What’s this change log that you’re looking at? I thought you said you couldn’t find one? Remember that the revision viewer tracks changes as they are submitted into CVS, so it will often contain changes that aren’t yet in any downloadable ROMs/modules/source zipfiles/etc.

What’s this change log that you’re looking at? I thought you said you couldn’t find one?

I couldn’t originally find one, but you pointed one out in your reply to my original post; that’s the one I’m referring to.

I tried the new ROM at the SAUG meeting this evening. It prevented the BB from driving my monitor at 1280×1024, so I’ve reverted for now to the 10-03-18 one.

Any idea why it was causing problems? The only change to the video driver between those dates should have been to enable the debugging code, which shouldn’t have any effect on the module’s functionality (unless you play around with the debug commands, obviously). It’s possible the serial port is slowing it down and causing something to go wrong, but AFAIK none of the bugs I’ve seen on my board are affected by enabling/disabling the debug code, and I’m able to run at 1280×1024x57Hz just fine with debugging enabled.

Sorry, I don’t know. I just did a straight swap to the new image; the first obvious difference was that it didn’t boot up in the high-res mode. The next observation was that it wasn’t possible to change it manually to the 1280×1024 resolution from the icon bar either, although we did get a somewhat higher resolution than default – IIRC it would have been 1024×768. I swapped back to the 10-03-18 image and it booted fine. I was at an SAUG meeting when I did it, and I had other things to try and to demo, so I couldn’t spend further time on it.

I can look again tonight. If anyone has any ideas of specific things I should look for, please post here!

Do you have something plugged into the serial port? Does it require a handshake line set so as not to slow it down?

Better news is that I was able to print from the BB directly from Gutenprint with Martin Wuerthner’s new PDumperGP module that he sent me for testing. This was with the 10-03-18 image again, though I can’t imagine the ROM image making any difference.

The serial port on the beagleboard doesn’t have any handshake signals, so everything should be fine there. If you can connect a serial cable then the output from the video driver might provide some clues as to why 1280×1024 wasn’t working.

I suppose you were using the same boot sequence each time, so it’s not something silly like *vidcbandwidthlimit not being called or the wrong MDF being used?

The serial port on the beagleboard doesn’t have any handshake signals, so everything should be fine there. If you can connect a serial cable then the output from the video driver might provide some clues as to why 1280×1024 wasn’t working.

OK… that’s a bit of a work-up; I haven’t used serial in years…

I suppose you were using the same boot sequence each time, so it’s not something silly like *vidcbandwidthlimit not being called or the wrong MDF being used?

Yes. Click on drive :0, double-click on !Boot, double-click on my “Go” Obey file. I don’t see how I could be asking it to do anything different.

Since you’re about to ask: I can’t check what’s in Go until I get home.