Problems building OMAP ROM
James Peacock (318) 129 posts |
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. Firstly the export headers phase for Kernel fails to export RISCOS and HALEntries because the following two commands in Kernel.Makefile fail to find hdr.RISCOS and hdr.HALEntries, eventhough they exist.perl Build:Hdr2H hdr.RISCOS $@ perl Build:Hdr2H hdr.HALEntries $@This started to work if I altered these to: 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 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? |
Chris Gransden (337) 1202 posts |
Could be you’ve another version of !Perl being seen by the filer or Alias$Perl is set. |
James Peacock (318) 129 posts |
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. |
Chris Gransden (337) 1202 posts |
A couple of other things to check. The RiscOS folders have all been merged together and !EraseCVS has been run on the folder. |
James Peacock (318) 129 posts |
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. The undefined instructions reported correspond to the following and can’t be decoded by Debugger 1.80:&E6FF0070 &E6FF0071 &E6FF2070 &E6BF1072 &E6BF3071 &E6BF1071 &E6BF2072 &E6FF0072 &E6FF0072 |
W P Blatchley (147) 247 posts |
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). |
James Peacock (318) 129 posts |
Adding a |
Ben Avison (25) 445 posts |
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? |
Rob Heaton (274) 515 posts |
I think this would be a great idea! |
Jeffrey Lee (213) 6048 posts |
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. |
Trevor Johnson (329) 1645 posts |
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? |
Chris Gransden (337) 1202 posts |
You can. You need to turn off alignment exceptions. Grab grep from here Then a set UnixEnv$egrep$nonametrans ”” The rest is the same. |
Trevor Johnson (329) 1645 posts |
Great and thanks for the extra advice too. |
Trevor Johnson (329) 1645 posts |
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 ? I’ve read the following wiki pages: Steps taken (from memory):
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. |
Jeffrey Lee (213) 6048 posts |
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.
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?
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. |
Trevor Johnson (329) 1645 posts |
I see.
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.
OK - The search didn’t pick that up and I didn’t think to check links from the main Cortex page .
Or I could have a go some time if you like. You could always correct my misunderstandings afterwards. |
Jeffrey Lee (213) 6048 posts |
It’s probably easiest for me to do it, since I’m more familiar with the build system. |
Trevor Johnson (329) 1645 posts |
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. |
Trevor Johnson (329) 1645 posts |
Perhaps this is unrelated, but would LayerFS simplify this? It’s been opensourced since last year.These folders need to be merged together for the build to work.I see. |
Jeffrey Lee (213) 6048 posts |
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 |
Trevor Johnson (329) 1645 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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 |
Trevor Johnson (329) 1645 posts |
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. |
Trevor Johnson (329) 1645 posts |
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?
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'.
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'etc.
Note, I did reboot and ran with alignment exceptions off this time. |
Jeffrey Lee (213) 6048 posts |
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.
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. |