Verify - Abort on data transfer

Is this a known issue? ROS 5.17 26/10/2011 BB xM rev C

On entering Verify from the command line the error, ‘Verifying… Abort on data transfer at &FC1D0904. Returning to the desktop generates the error box, ’Message from pinboard’ – ‘File core in use’ and clearing this returns to the desktop with no backdrop image. Accessing the drive icon then produces a ‘Filecore in use’ message as does shutdown.

Using Verify from the desktop filer icon works as expected and DiscKnight reports no issues. I’m not aware of other problems.

I get the exact same problem here. I’m using a ROM I built on 24/12/2011.

Confirmed. It’s doing an unaligned LDR of DiscRecord_ZoneSpare.
Amusingly in the source code there’s even an ‘ASSERT’ on the line above to check it’s unaligned.
Fixed in FileCore 3.48.

Thanks for the quick fix Sprow!

An updated OMAP3 ROM is available here – http://robheaton.co.uk/riscos/roms/5.19-omap3.zip
Welcome to RISC OS 5.19 everyone!!

What took so long! :-)

I’m confused about the version numbering. I know odd numbers are supposed to be development and even release but where does 5.18 fit in?

I’m confused about the version numbering. Where does 5.18 fit in?

5.18 is currently being made to sweat on a treadmill with selected testers.

A lot of stuff on the downloads page is automatically generated from CVS so there’s a paradox that you need to check everything in before you get something back – we’re currently in that transition period where 5.19 can be produced but while 5.18 isn’t yet out. It’s on its way.

Ah, OK. 5.19 boots fine for me and it’s nice that CMOS no longer needs a bodge.

Command line Verify now completes instantly for my 8GB USB stick as opposed to the desktop’s extended delay. Is that as it should be?

5.19 boots fine for me and it’s nice that CMOS no longer needs a bodge

I think that the ROM Rob Heaton generated predates the change to the HAL to support real EEPROM by about 2 hours.

Command line Verify now completes instantly for my 8GB USB stick as opposed to the desktop’s extended delay. Is that as it should be?

Command line verify uses DiscOp_Verify which SCSIFS ignores (source file ScsiFs15 line 67). I don’t know anything about SCSI but it probably has a good reason for doing so.

Desktop verify spends a lot of time drawing nice progress bars.

I think that the ROM Rob Heaton generated predates the change to the HAL to support real EEPROM by about 2 hours.

I’ve rebuilt the OMAP3 ROM, it now includes the change to the HAL.
http://robheaton.co.uk/riscos/roms/5.19-omap3.zip

I think that the ROM Rob Heaton generated predates the change to the HAL to support real EEPROM by about 2 hours.

The previous ROM I used was from October so the bodge was Howard Dawson’s BB_CMOS. Now not needed.

Real EEPROM? BB-xM?

DiscOp_Verify which SCSIFS ignores

Ta.

I’ve rebuilt the OMAP3 ROM, it now includes the change to the HAL

Ooer! Ships in the night.

Real EEPROM? BB-xM?

The carrier boards are due next week (I’m using a hand soldered one) and will be distributed to those with ARMini (or in their support scheme) via RComp at some point. For DIYers you can probably guess which stockists may have them.

I didn’t know there were plans afoot to release an EEPROM! I’ll have to keep an eye out!

A call to worthing?

Where do they fit? Plug in, I hope.

The change to the HAL to support real EEPROM

Ah, It’s clicked. Having updated to the new new ROM image I see that, with the change to the HAL, ‘CMOS’ save to SD card has been removed.

I’ve rebuilt the OMAP3 ROM, it now includes the change to the HAL

I wonder if I’m missing something here. Using this latest ROM, I can only get to the supervisor prompt. Do I need to do anything else to the SD card?

I get the same issue, the latest ROM seems to ignore the CMOS file on the SD card.
I found from the supervisor prompt the machine is now defaulting to drive 0.

Looking at the CVS check in – https://www.riscosopen.org/viewer/revisions/logs?ident=1325971332-331698.html
It looks as if the boot script needs updating with;
fatload mmc 0:1 0×4020F000 cmos

One downside of downloading a ROM from Rob’s private website is that it’s missing some of the other stuff that the autobuilder gives you.

While waiting for the EEPROM carriers to turn up you can edit your uboot startup script uenv.txt to load the CMOS file. There are also updated boot scripts (things ending in ‘scr’) if you still require those.

Eventually I forsee this option being turned off, but it’s a useful transition aid.

I’ve gone back to using BB_CMOS for now, which is fine. Had to re-introduce the Num lock FXs later in the boot sequence but I’m more likely to remember to delete these when no longer needed.

One downside of downloading a ROM from Rob’s private website is that it’s missing some of the other stuff that the autobuilder gives you.

What else do I need to add to the ROM downloads? If the licence permits it, I can add anything else that may be needed.

What else do I need to add to the ROM downloads?

Just download one of the ROOL ones for an idea. This final “licence terms + readme + zip it up” step is done by ‘ABRelease’ which is also in CVS, so you should be able to automate it if you can figure out how to set it all up.

Cheers! I’ll take a look at a ROOL ROM download. I don’t think I’ve used any for a long time, I’ve always built my own!

Okay, I’ve had a look at the ROOL ROM download, I already distribute the licence terms, I’ll create a new up to date readme file, and contact Jeffrey Lee about distributing !SDCreate.

I have the basics of an autobuilder, though I really need to finish writing it!

Real EEPROM? BB-xM?

The carrier boards are due next week (I’m using a hand soldered one) and will be distributed to those with ARMini (or in their support scheme) via RComp at some point. For DIYers you can probably guess which stockists may have them.

Any news on this front?

Real EEPROM? BB-xM?

Any news on this front?

Production boards sitting in a box awaiting 5.18 to use them. I believe that’s finished sweating on the treadmill and is now relaxing in the spa pool prior to release.

That’s good. They should arrive nice & shiny, then.

Mmmm, Shiny!