Problems building OMAP ROM

I’ve been attempting to build an OMAP ROM (source checked out for OMAP3Dev) and have two problems which are stopping it from being built.

  perl Build:Hdr2H hdr.RISCOS $@
  perl Build:Hdr2H hdr.HALEntries $@

  perl Build:Hdr2H @.hdr.RISCOS $@
  perl Build:Hdr2H @.hdr.HALEntries $@

A bigger problem is that SpriteExtend fails to build. Its build process used cc to generate an assembler file putscaled.s which is then patched using sed before getting compiled using objasm. The problem is that the assembler generated by cc has Undefined instruction appearing at various points which objasm doesn’t like.

I have cc 5.65 and objasm 3.32.

Given that others here seem to be building the ROM without problem, I’m wondering what I’m doing wrong.

Any ideas?

Could be you’ve another version of !Perl being seen by the filer or Alias$Perl is set.

Yes, thanks. First problem is down to perl. I have an Obey file which (was meant) to clear all the perl system variables and boot the ROOL perl, however due to a typo, it was clearing Alias@Perl. Funny thing is that I’ve being using that Obey file for ages, which I why I didn’t think to check it.

Anyway, perl problem fixed and starting with a fresh source tree, I still get the failure to build SpriteExtend.

A couple of other things to check. The RiscOS folders have all been merged together and !EraseCVS has been run on the folder.

I merged them together using rsync as specified somewhere here. If I remove SpriteExtend from the list of modules I can produce a ROM which boots on the beagleboard. It does appear that the problem is restricted to SpriteExtend.

  &E6FF0070
  &E6FF0071
  &E6FF2070
  &E6BF1072
  &E6BF3071
  &E6BF1071
  &E6BF2072
  &E6FF0072
  &E6FF0072

Hi James,

Do either of these threads help:

https://www.riscosopen.org/forum/forums/5/topics/261

https://www.riscosopen.org/forum/forums/3/topics/207

Sounds similar to your problem (ARMv6 instructions).

Adding a -cpu arm7 to the cc command used to generate the pre-patched assembler lets SpriteExtend build. So it looks as if the problem is that cc attempts to generate assembler output that it itself does not understand.

The SpriteExtend undefined instruction problem was due to a fault in versions of CC prior to 5.67 – see this post in particular:

https://www.riscosopen.org/forum/forums/3/topics/207#posts-1413

We’ve contemplated offering online upgrades for owners of recent toolchains to save the cost and effort of shipping physical upgrades CDs – although the effort required on the website to achieve that is considerable too. How much interest would there be in such an option?

We’ve contemplated offering online upgrades for owners of recent toolchains to save the cost and effort of shipping physical upgrades CDs – although the effort required on the website to achieve that is considerable too. How much interest would there be in such an option?

I think this would be a great idea!

I’d definitely be interested in online upgrades as well – although it doesn’t bother me too much if it has to be done by post. A much more useful thing might simply be an up to date changelist on the site somewhere, so we can see if all the big bugs have been fixed yet.

I’m interested in trying to do a ROM build on the BeagleBoard. Neither the Build FAQ nor the Cortex-A8 port source code pages seem to indicate whether this is possible or not. (I know I’ll have to buy the Acorn/Castle/ROOL C/C++ suite first.)

Yes/no?

You can.

You need to turn off alignment exceptions. Grab grep from here

Then a set UnixEnv$egrep$nonametrans ””

The rest is the same.

Great and thanks for the extra advice too.

I’m getting somewhere with following the build procedure (on the BeagleBoard) but am wondering if it’s normal that I should have to copy (or move?) the Env and Library directories in order to advance with Builder. Also, what is meant by merging the RISCOS folders together ?

• Developer’s guide to RISC OS builds
• How to build RISC OS
• Build FAQ

1. Download and extract src-omap
2. Make a copy of the extracted sources this in $.RISCOS
3. Run EraseCVS
4. Run the InstallTools script
5. Didn’t reboot, i.e. C/C++ tools installation had been seen by the filer – oops, will correct this next time
6. Forgot about the need to turn off alignment exceptions etc. – oops again, ditto (Incidentally, can I use this RiscOS/Tools/Sources/GNU/grep instead?)
7. Run Builder and set directories for source/environment
8. Choose an environment (e.g. ROOL OMAP, BuildSys) and attempt build

Are there any other hints that may be useful before I return to this over the weekend? When I’ve understood things a little better, I can update the Build FAQ in case anyone else has similar misunderstandings. Thanks.

Also, what is meant by merging the RISCOS folders together ?

If you grab the source from CVS then you’ll end up with three or four folders (castle, mixed, gpl, and bsd). These folders need to be merged together for the build to work. If the downloadable source archives aren’t structured like that then I guess you don’t need to worry about it.

I’m getting somewhere with following the build procedure but am wondering if it’s normal that I should have to copy (or move?) the Env and Library directories in order to advance with Builder.

It’s not normal to have to do that, no. Maybe you were only having problems because the C/C++ tools had been seen by the filer?

Are there another other hints that may be useful before I return to this over the weekend? When I’ve understood things a little better, I can update the Build FAQ in case anyone else has similar misunderstandings. Thanks.

Updating the build FAQ would be good :)

There’s a page here linked to from the main Cortex page which deals with setting up a source tree from CVS. But it doesn’t deal with doing a build on the beagleboard itself. Really all the different “how to build RISC OS” pages could do with updating/rewriting to reflect the current state of how to build the code and all the little steps that must be followed along the way. Maybe I should have a trawl through the wiki over the weekend and have a go at rewriting them.

These folders need to be merged together for the build to work.

I see.

If the downloadable source archives aren’t structured like that then I guess you don’t need to worry about it.

AFAICR they are.

...normal that I should have to copy (or move?) the Env and Library directories?

It’s not normal to have to do that, no. Maybe you were only having problems because the C/C++ tools had been seen by the filer?

Thanks. Maybe the merging will help too.

There’s a page here linked to from the main Cortex page which deals with setting up a source tree…

OK - The search didn’t pick that up and I didn’t think to check links from the main Cortex page .

Updating the build FAQ would be good :) ...Maybe I should have a trawl through the wiki over the weekend and have a go at rewriting them.

Or I could have a go some time if you like. You could always correct my misunderstandings afterwards.

Or I could have a go some time if you like. You could always correct my misunderstandings afterwards.

It’s probably easiest for me to do it, since I’m more familiar with the build system.

Of course. You may have noticed that I’ve slightly amended the Build FAQ to make it easier to navigate. I’ve also added a “What other relevant documentation should I read?” question.

These folders need to be merged together for the build to work.

I see.

Possibly – James Peacock has had a quick play with it here. Although ROOL were also experimenting with changing the build system so that the merge/CVS clean wouldn’t be required – see here

Thanks. I must’ve actually read those before, not that it’d really have sunk in without me having the tools or having attempted a build at the time.

If you’re trying to build the OMAP ROM, I’ll warn you now that it’s been broken for the past 5 weeks! A change I made resulted in a compile error, which I somehow didn’t spot, and annoyingly didn’t result in the build failing since I still had a valid object file from an earlier build.

It’s only a one-line fix for the video driver, so it’s probably easiest for you to do it yourself rather than download a fresh source archive once the relevant ones have been rebuilt. You’ll need to change ‘u32 *regs’ to ‘volatile u32 *regs’, as indicated in this diff

Thanks very much. The log refers to a fatal error running ‘SharedRISC_OSLib’ but I’ve not really had a chance yet to look any further into why I can’t get it working. Will try your suggestion regarding the video driver too.

Here’s a list of steps taken – I must still be missing something. Any more pointers, please? Or do I need to begin wading through the C/C++ tools docs now, just in order to build the ROM?

• Merged all ’...RiscOS’ folders into ’...castle.RiscOS’
• Moved contents of ’...castle.RiscOS’ to $.RISCOS (Builder reporting not being able to locate ‘Libraries’ AFAICR)
• Built ROOL.OMAP3 with
  • Clean
  • Clean All
  • Export headers
  • Export libraries
  • Export resources
  • Make ROM
  • Install ROM
  • Join ROM

SharedRISC_OSLib...
amu -E  rom_link ADDRESS=4229110768 LINKDIR=SCSI::HardDisc0.$.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]
fc135bfc 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'.

• Built ROOL.BuildEnv with
  • List
  • Clean
  • Clean All
  • Export headers
  • Export libraries

Batched errors...
Error cannot locate 'SCSI::HardDisc0.$.RISCOS.Sources.HWSupport.ARM3'
Error cannot locate 'SCSI::HardDisc0.$.RISCOS.Sources.HWSupport.CD.ATAPI'
Error cannot locate 'SCSI::HardDisc0.$.RISCOS.Sources.FileSys.CDFS.CDFS'
Error cannot locate 'SCSI::HardDisc0.$.RISCOS.Sources.HWSupport.CD.CDFSDriver'

• • (No postmortems)

• Built ROOL.OMAP3 again with
  • Make ROM
  • Install ROM
  • Join ROM
• Bathced errors as before for ROOL.OMAP3 (checked visually as haven’t checked the manuals for using Diff yet).

Note, I did reboot and ran with alignment exceptions off this time.

egrep -v "^(0x00000000 . )?_swix?$" < syms.A_Entries1 > syms.A_Entries

Internal error: undefined instruction at &000212BA

Looks like the version of egrep you’re using isn’t ARMv7-safe.

Built ROOL.BuildEnv

You won’t be able to build BuildEnv using the OMAP source archive, since it requires extra components which aren’t in the OMAP build (as you can probably tell by the errors!). I think BuildEnv is only really relevant if you’ve got the entire CVS tree on your machine, and you want to use it as a time-saving device for when you need to perform multiple builds of different products.