Problems building OMAP ROM

It starts off empty.

It started off non-existent: I’m pretty certain that Builder created it. And then failed to save the image there.

It started off non-existent: I’m pretty certain that Builder created it. And then failed to save the image there.

But your build didn’t complete without errors, did it? There won’t be an image to save unless the build process completed with no errors.

[Edit: If it’s not a silly question, do I need the full ‘cvs-repos’ tarball too, and merge that with the ‘src-omap.5.17’ one?]

The src-omap, src-tungsten, src-disc, etc. archives should contain everything you need to build the corresponding product.

Rather than try and post the full build log somewhere, what about just posting the last part of the log, containing the output for the last component it tried to build? Although there may well be errors elsewhere in the log, chances are that any components which are failing will all be failing due to the same (or similar) reasons.

The src-omap, src-tungsten, src-disc, etc. archives should contain everything you need to build the corresponding product.

Good stuff :-)

Rather than try and post the full build log somewhere, what about just posting the last part of the log, containing the output for the last component it tried to build?

How’s this? It doesn’t look good!

Desktop...
amu -E  install_rom INSTDIR=SCSI::HardDisc1.$.RO.RiscOS.Install.ROOL.OMAP3.Desktop COMPONENT=Desktop TARGET=Desktop 
copy  rm.CortexA8.Desktop SCSI::HardDisc1.$.RO.RiscOS.Install.ROOL.OMAP3.Desktop.Desktop FR~C~V~N
Desktop: rom module installed

SharedRISC_OSLib...
amu -E  rom_link ADDRESS=4229094052 LINKDIR=SCSI::HardDisc1.$.RO.RiscOS.Install.ROOL.OMAP3.Lib COMPONENT=SharedRISC_OSLib TARGET=RISC_OSLib 
do <Perl$Dir>.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$Dir>.perl build:xtentries > syms.A_Entries1 kernel.s.k_entries clib.s.cl_entries
egrep -v "^(0x00000000 . )?_swix?$" < syms.A_Entries1 > syms.A_Entries

Internal error: undefined instruction at &000212BA

Postmortem requested
212b6 in anonymous function
  Arg2: 0x000216c8 136904 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe15d000a]
  Arg1: 0x00025e20 155168 -> [0x65726765 0x762d2070 0x285e2220 0x30307830]
fc131ab0 in shared library function
83ec in function ___init
AMU: *** exit (1) ***

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::HardDisc1.$.RO.RiscOS.BuildSys.Logs.aUI800-00'.

Wasn’t that issue also sorted on this very thread ?

Hmm, it looks like it. Thanks.

Talking of builds, I’m in the process of testing the changes that I’ve added to CVS which affect how we do builds on RISC OS. Basically, the aim is to simplify setting up the build environment and avoid the need to merge “castle”, “bsd”, etc subdirectories. Keep an eye on the wiki pages for more information. At the moment, it’s possible that the “Dev” builds in particular could be broken by these changes.

Grrr. After setting UnixEnv$egrep$nonametrans and using the ARMv7-safe grep, I now have an unknown opcode error in the “Untested, but should be safe” castle/RiscOS/Sources/Networking/BBCEconet/s/BBCEconet :-(

[Edit: But that dates back to May 2009, so how come no one else has had a problem with it?]

Oops – it’s actually in s/Interface. But that still makes no sense because I don’t have last night’s change in the sources I downloaded the other day.

I now see that the build log shows this was the ASR and ASL opcodes, which have now been changed.

Talking of builds, I’m in the process of testing the changes that I’ve added to CVS which affect how we do builds on RISC OS.

So I think I’ll wait until the outcome of your testing is known before I bother downloading and extracting another tarball. With all this ROOL activity (including the behind-the-scenes stuff, of which I’m sure we don’t know the half of) I’m wondering whether you guys have taken a few weeks leave from work or perhaps even become hermits!

There is some work in progress at the moment, migrating to a newer way of building and paving the way for improvements in the toolchain. I have nearly got all the builds working again but it’s going to take a few more hours. The nightly builds of the various tarballs should deliver working build archives again as from tonight (or early tomorrow morning). I’ll also be writing this all up on the wiki.

Nice one – thanks for the update :-)

The src-omap, src-tungsten, src-disc, etc. archives should contain everything you need to build the corresponding product.

[…] migrating to a newer way of building […]

I guess the migration’s still being worked on, but in case it goes unnoticed:

• This morning’s¹ ‘src-omap.5.17.tar.bz2’ archive doesn’t seem to include ‘castle/RiscOS/Apps/’ so the new !Builder (including the fix for Ticket #131) is missing. [Edit: Oh yes it does!]
• Should ‘Prepare/’ be named ‘!Prepare/’?

¹ 2011-03-21 03:41:12

Hi. When I committed Prepare into cvs I used a pling but cvs refused to check it back out. I tried escaping of course. I reckon there’s something magic about the root directory. So I had to rename it. Shame because it ruins the elegant simplicity of my plan. You now have to double click !Run inside Prepare to run it.

Also note, I made a start on the wiki documentation but my session timed out and I lost my work. Now building up the willpower to start again. Argh.

Also note, I made a start on the wiki documentation but my session timed out and I lost my work.

There’s something odd going on with Hub – sessions are expiring when they shouldn’t. I had it log me out just after committing a Wiki settings change a moment ago, so essentially there was zero timeout. Not sure why; investigating.

…and either way, Changeset #417 should help a bit.

BBCEconet

I now see that the build log shows this was the ASR and ASL opcodes, which have now been changed.

BBCEconet (castle.RiscOS.Sources.Networking.BBCEconet)...
amu -E  install_rom INSTDIR=SCSI::HardDisc1.$.RO.Install.ROOL.OMAP3.Networking COMPONENT=BBCEconet TARGET=BBCEconet 
copy  rm.CortexA8.BBCEconet SCSI::HardDisc1.$.RO.Install.ROOL.OMAP3.Networking.BBCEconet FR~C~V~N
BBCEconet: rom module installed

:-)

ROMFonts (castle.RiscOS.Sources.Video.Render.Fonts.ROMFonts)...
amu -E  install_rom INSTDIR=SCSI::HardDisc1.$.RO.Install.ROOL.OMAP3.Video COMPONENT=ROMFonts TARGET=ROMFonts 
do mkdir -p o
objasm -depend !Depend -Stamp -o o.Iyonix s.ROMFonts
ARM AOF Macro Assembler 3.32 (Acorn Computers Ltd) [20 May 2010]
Error: File 'Fonts.Trinity.Medium.Italic.Outlines0' not found at line 44 in macro ResourceFile
 at line 247 in macro MyDesk
 at line 66 in file s.<UserIF>_Fonts
 included by GET/INCLUDE directive at line 252 in file "s.ROMFonts"
   44 0004b988         DCD     :FLOAD:"Fonts.Trinity.Medium.Italic.Outlines0"  ; Load address of file
Error: File 'Fonts.Trinity.Medium.Italic.Outlines0' not found at line 45 in macro ResourceFile
 at line 247 in macro MyDesk
 at line 66 in file s.<UserIF>_Fonts
 included by GET/INCLUDE directive at line 252 in file "s.ROMFonts"
   45 0004b98c         DCD     :FEXEC:"Fonts.Trinity.Medium.Italic.Outlines0"  ; Exec address of file
Error: File 'Fonts.Trinity.Medium.Italic.Outlines0' not found at line 46 in macro ResourceFile
 at line 247 in macro MyDesk
 at line 66 in file s.<UserIF>_Fonts
 included by GET/INCLUDE directive at line 252 in file "s.ROMFonts"
   46 0004b990         DCD     :FSIZE:"Fonts.Trinity.Medium.Italic.Outlines0"  ; The length of the file
Error: File "Fonts.Trinity.Medium.Italic.Outlines0" not found at line 52 in macro ResourceFile
 at line 247 in macro MyDesk
 at line 66 in file s.<UserIF>_Fonts
 included by GET/INCLUDE directive at line 252 in file "s.ROMFonts"
   52 0004b9c4         BIN     Fonts.Trinity.Medium.Italic.Outlines0           ; The file itself
Fatal error: Structure mismatch at line 52 in macro MyDesk
 at line 66 in file s.<UserIF>_Fonts
 included by GET/INCLUDE directive at line 252 in file "s.ROMFonts"
   52 0004b9c4         BIN     Fonts.Trinity.Medium.Italic.Outlines0           ; The file itself
Assembly terminated: 
5 Errors, 0 Warnings
AMU: *** exit (8) ***

AMU: *** 'install_rom' not re-made because of errors ***

Error running make install_rom on module 'ROMFonts'.
Fatal error running make install_rom on module 'ROMFonts'.
Batched errors...
Error running make install_rom on module 'ROMFonts'.

(There are further apparently related ROMFonts errors further up the build log.) :-(

castle/RiscOS/Sources/Video/Render/Fonts/ROMFonts/Fonts/Trinity/Medium/Italic/ seems to be present in the same format as the rest¹. And If I’m right in thinking it’s not the first in the list, then I guess the others built OK (or even ROMFonts/s/Iyonix_Fonts, as per this post). I don’t know where to find macro ResourceFile

¹ In CVS, anyway. I’ll check my extracted build tree later.

isn’t Fonts.Trinity.Medium.Italic.Outlines0 the file that always gets some stuff appended to its name during the de-tarballing process?

[…] gets some stuff appended to its name during the de-tarballing process?

You’re probably right: I need to check my extracted build tree. Does anyone know the cause of this?

Anyway, the new ‘Prepare’ scripts certainly simplify things, although I did have one ‘OMAP3Dev’ directory inside another (IIRC), so I moved it first. Was that unnecessary? Sorry to hear about the wiki page timeout – it’s just typical when you’ve typed in more than a screenful!

Does anyone know the cause of this?

It’ll be this problem, surely?

Any ETA on a fixed !UnTarBZ2, Steve?

Let me ask a more basic question: why use the tar/bz2 format? Does it achieve any more than zip from SparkFS would? And I bet that SparkFS will get the path names right, too.

Here’s my version of untarbz2 which understands the ustar long filename extension.

SparkFS doesn’t get the filenames right – it doesn’t recognise the ustar extension to tar

It’ll be this problem, surely?

I’ve still to check my source tree, but isn’t the (longer) Fonts/Homerton/Medium/Oblique/ dealt with before Fonts/Trinity/Medium/Italic/?

Here’s my version of untarbz2 which understands the ustar long filename extension.

Thanks – I should be able to try that tonight.

isn’t the (longer) Fonts/Homerton/Medium/Oblique/ dealt with before Fonts/Trinity/Medium/Italic/?

My build log contains no refs to ‘Homerton’, so I s’pose not!