Error booting latest downloadable Beagle ROM

I get an abort if I save the ‘Desktop Settings’ from the Task menu. &FC1D6ADC in module filer. Then on boot up I get an abort &FC1696CC in ADFSFiler. It goes away if I delete the !Boot file the save creates.

With the latest rom build the date and time isn’t getting set on boot up. If I reboot with a previous rom build the date and time is set correctly.

Both of these should be fixed now.

Thanks. Both fixed.

Further to the ram disc abort. Occasionally when I quit the ram disc i get an abort at &FC1699A4 in module ADFSFiler.

StrongED 4.69a1 is now available. The memory transfer routines have been modified such that they no longer assume that LDM/STM ignore the bottom two bits of the memory address.

What remains to be done is to fully test the changes made, hence this release. Of course, it’s entirely possible that there are further unaligned memory accesses. Should you find any then please let me know and I’ll fix them asap.

The changes made should probably also be applied to StrongHelp and StrongMen – they use the library as StrongED does. Let me know if you’re interested.

StrongED 4.69a1 can be found here: http://www.stronged.iconbar.com/archives/releases/se469a1.zip

StrongED 4.69a1 is now available

Excellent! The task window now works in StrongED, good to have it back!

Excellent! The task window now works in StrongED, good to have it back!

Glad to hear it’s working okay!

I’ve also put up an updated version of StrongHelp (2.85a). If it’s been confirmed to work I’ll pass along my changes to Christian Ludlam so that he can make a formal release.

StrongHelp 2.85a can be downloaded from: http://www.stronged.iconbar.com/archives/misc/sh285a.zip

Thanks Fred, I’ll test the updated StrongHelp tonight, once I get home from work. I’ll post my results later.

Rob.

I’ve been using the updated version of StrongHelp, and so far I’ve not had any problems! Great work Fred!

I’ve just built the OMAP ROM on my DevKit8000 board !!!
One fault with my first attempt, but a quick reply from Ben Avison put me on the right track.
It seems the “grep” absolute needed a slightly later version. A quick search gave me Darren Salts version (2.5.1).
Using that the build completed and is now running on my board.
This is with alignment exceptions turned off.
With them on, instant fail without a log file.

Just ran the build again.
With List, Clean, Clean All, Export headers, Export libraries and Export resources ticked it takes 16 mins and 37 seconds.
With Make ROM, Install ROM and Join ROM ticked it takes 22 mins and 13 seconds.

grep, et al. riscos.info has ports of pretty much all these tools. I know there are lots of older ports of stuff floating around, and it can be confusing, so the hope is to be the central location of latest versions of stuff.

Sometimes things haven’t been fully packaged or 100% tested, but this is usually quickly remedied. grep is here:

http://www.riscos.info/packages/UtilitiesDetails.html#grep

Just to let everyone know, the build using the “grep” Peter points to fails. The last part of the log below.

SharedRISC_OSLib…
amu -E rom_link ADDRESS=4229109588
LINKDIR=SCSI::HardDisc4.$.omap.RiscOS.Install.ROOL.OMAP3.Lib
COMPONENT=SharedRISC_OSLib TARGET=RISC_OSLib
do <perl>.perl build:xtentries > syms.C_Entries kernel.s.k_entries
kernel.s.k_entries2 clib.s.cl_entries clib.s.cl_entry2
print rlib.swi { >> syms.C_Entries }
do <perl>.perl build:xtentries > syms.A_Entries1 kernel.s.k_entries clib.s.cl_entries
egrep -v ”^(0×00000000 . )?_swix?$” < syms.A_Entries1 > syms.A_Entries

Cannot open syms.A_Entries1 for I/O redirection
AMU: exit (129)

AMU: ‘rom_link’ not re-made because of errors

Error running make rom_link on module ‘SharedRISC_OSLib’.
Fatal error running make rom_link on module ‘SharedRISC_OSLib’.
Batched errors…
Error running make rom_link on module ‘SharedRISC_OSLib’.

---

Closing log file ‘SCSI::HardDisc4.$.omap.RiscOS.BuildSys.Logs.pUI800-00’.

The lastest OMAP rom hangs for me. Just get a blank screen.

Here’s whats on the serial console.

4194304 bytes read

1. Starting application at 0×81000000 …

OMAP3 HAL init

Board config=BeagleBoard

HAL_Init

Performing DSS reset

DSS init

Yeah, looks like I missed checking in one of the files. CVS should be fixed now – I’m about to try a clean build myself just to make sure.

Thanks. It worked. I’m now running 5.17.

I’m getting a hang at the beagleboard splash screen with the latest OMAP rom.

The serial console just gets to Starting application at 0×81000000.

Took me a while to get it to build as I didn’t notice initially there’s a new bsd folder to merge.

That’s unexpected – it should at least get to the “OMAP HAL init, board config=xxx” stage. Are sure you updated to the latest code properly? If you’re using an existing build tree, have you tried cleaning & rebuilding everything from withing !Builder? I can check when I get home, but nothing’s changed that could cause it to die before printing the board type :(

I downloaded the source and built it again. This time it worked. :-)

newer versions of egrep seem to prefer a ’/’ instead of a ’.’ in filenames. After upgrading egrep (since the one from the build tree does not run on the OMAP) I have tried to build a ROM but it kept failing over the egrep command. Changing the ’.’ to ’/’ in the filenames of the Makefile egrep command makes it build.

EDIT: for some reason egrep just decided that it prefers a ’.’ over a ’/’ now. weird. ah-well, it compiles and that’s what is important.

If it’s the egrep from the GCCSDk autobuilder you should be able to ‘set UnixEnv$egrep$nonametrans ””’