OMAP3 build oddities

Has anyone tried building the OMAP3 sources from scratch recently?

I downloaded the tarball on Sunday or Monday. Here are the oddities:

1) UnTarBZ2 has to be run with alignment exceptions off. If not, the
error message doesn’t suggest an AE issue at all – it’s quite
misleading. But if AE on or off makes a difference, it must be
performing unaligned word loads and/or stores, mustn’t it, so can
it work on the Iyonix? (I haven’t tried, that’s simply a question.)

2) I dragged the RISCOS directories from inside the “bsd”, “castle”,
“gpl” and “mixed” directories into the BB’s root directory and
started a build. It errored out immediately because it couldn’t
find “$.RISCOS.castle.Sources.Programmer.HdrSrc” and other files,
because the “castle” part of the path doesn’t exist.

3) So I deleted the $.RISCOS directory and created it again, this
time dragging the “castle” directory into “$.RISCOS” instead. The
build went for a few minutes before it opened an error window that
showed that “^.Sources.ToBuffer” (sorry, I don’t know where this
file is) couldn’t open “Desk.Debug.h”. (The cascade of errors that
followed will probably go away when the files are all in the right
places.)

4) Much later, the build ended with a long list of missing files,
beginning with:

$.RISCOS.bsd.RiscOS.Sources.Video.HWSupport.OMAPVideo
$.RISCOS.mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build
$.RISCOS.mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build
$.RISCOS.mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build
$.RISCOS.mixed.RiscOS.Sources.HWSupport.USB.Controllers.OHCIDriver
$.RISCOS.mixed.RiscOS.Sources.HWSupport.USB.Controllers.MUSBDriver
$.RISCOS.mixed.RiscOS.Sources.HWSupport.FPASC.riscos

So I’ve still got to find those.

5) While trying to work out where “Sources.ToBuffer” is (step 3),
a search showed that directories
$.RISCOS.castle.RiscOS.Sources.Lib.PlainArgv.o.Sources.Sources.c and
$.RISCOS.Sources.Lib.PlainArgv.o.Sources.Sources.c
both have apparently identical copies of files CFileName, CopyPArgv,
Find, Get, StrTok and ToBuffer. Why are there two identical copies
of 6 files, and why are they somewhere inside an “o” directory,
which is normally for object files?

Confused…

Aha, I see that the build instructions are very different now. I was following my own notes from a few months back. Serves me right, I suppose… :-)

But the much more serious problem is that, two times out of two, the build process locked the BeagleBoard up after maybe 25 minutes. This is absolutely not normal for my BB. The mouse cursor and the lock keys/LEDs were working, but nothing else. Not even Alt-Break would stop it; I had to remove power.

Dave, I had these problems when working with older USB Sticks – could this be the cause? Alternatively, with a Beagleboard XM it might be possible to build on the RAM disc – being much faster and avoiding the above problem as well. using the Hard disc or an SD card attached via card reader, the problem didn’t occur.

My BB has a 250 GB rotating drive, not a USB stick. DiscKnight shows the disc to be OK.

I don’t have an XM, but the idea of building from a RAM disc is interesting. It still doesn’t explain why the build is failing, though.

Thanks for the thoughts and ideas.

Nearly there…

The third time died in the same way, but the fourth time got much further. Here are the last few lines of the log:

SharedRISC_OSLib (castle.RiscOS.Sources.Lib.RISC_OSLib)...
amu -E  rom_link ADDRESS=4229126392 LINKDIR=SCSI::HardDisc4.$.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

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.$.RISCOS.BuildSys.Logs.dUI800-00'.

Now SCSI::HardDisc4.$.RISCOS.castle.RiscOS.Sources.Lib.RISC_OSLib.syms exists, contains files A_Entries1 and C_Entries, and both those files are readable.

Any ideas?

Have a look through this thread, and see if it might be related. Mainly the bottom of page 1 and halfway down page 2.

Unfortunately, it seems that giving my BB any long disc-intensive task causes it to stop responding after a while. It happens during UnTarBZ2 or the build process.

Earlier this year I had no problem repeatedly building the HAL. Something seems to have changed. I need to see if reverting to an earlier version of RISC OS makes any difference. That is, if I’ve kept any earlier version.

If no-one else can help quicker, email me as I should have copies of earlier versions on my BB at home going back to Jan of this year.

Actually, just realsied I can access them from here, so can send you them straight away, hopefully. Let me know what you need.

I think the last time any significant changes were made to the USB/SCSI drivers was back in November of last year, so I’m not quite sure what could cause things to recently start failing for you. I’ll have a go at setting a ROM build going tonight and see if anything bad happens for me.

I think the last time any significant changes were made to the USB/SCSI drivers was back in November of last year

Scratch that; I forgot that I did quite a bit of work on MUSBDriver a few months ago. Is it the OTG port that you’ve got the disc connected to or the host port?

I started a build running this morning (on one of the host ports on my xM), so I should be able to report back with my findings tonight.

Scratch that; I forgot that I did quite a bit of work on MUSBDriver a few months ago.

I thought so.

Is it the OTG port that you’ve got the disc connected to or the host port?

It’s the host port, via a 7 port hub that has been permanently attached to the BB since day 1. What is plugged into the hub hasn’t changed in months. I’ve never even attempted to use the OTG port.

I guess it’s possible that the HDD is failing (it’s still not all that old, but anything can fail), but I thought that failures normally resulted in an error message of some kind rather than a lock up.

I did quite a bit of work on MUSBDriver a few months ago.

I know it’s off topic for this thread, but do you have any ideas for this? Or, assuming I can get RO to build again, can you point me at where to look? I have tried once or twice to look at the USB code, but I’ve never been able to make head nor tail of it.

I know it’s off topic for this thread, but do you have any ideas for this? Or, assuming I can get RO to build again, can you point me at where to look? I have tried once or twice to look at the USB code, but I’ve never been able to make head nor tail of it.

As far as I know the core NetBSD code reports the transfer lengths correctly, so the problem would likely be in the DeviceFS interface. This is handled in usbmodule.c. It looks like it’s the get_buffer_space function which handles the call which you’re using, and the read_cb function which is called by the NetBSD code once a transfer has completed and the data has been inserted into the buffer managers buffer.

I started a build running this morning (on one of the host ports on my xM), so I should be able to report back with my findings tonight.

I ran a few builds and didn’t encounter any problems, so it doesn’t look like it’s a general issue with performing builds on a beagleboard.

I ran a few builds and didn’t encounter any problems, so it doesn’t look like it’s a general issue with performing builds on a beagleboard.

I’m sure it’s not, or others would have reported it by now. I have no reason to believe it’s specific to builds, even. My guess is that it’s associated with lots of disc activity, and/or lots of taskwindow activity – not sure about the latter, as it happened to me during an UnTarBZ2 operation, and I don’t know what sort of window !UnTarBZ2 uses for output when run from its GUI.

The challenge is to identify what’s faulty on my system, and why it wasn’t faulty earlier this year when I was doing lots of this sort of stuff.

Last night I downloaded the 2011-09-02 binary and attempted to UnTarBZ2 the current OMAP sources. The BB locked again after a few minutes.

In a move that could be considered either brave or foolhardy, I unplugged the HDD. Lo and behold, after a few seconds a box popped up asking me to insert HardDisc4. When I did, the BB was back to being usable again (the UnTarBZ2 operation had failed, as one would expect).

In a truly foolhardy move, I plugged the HDD back in again and repeated the UnTarBZ2 operation, without even a disc check or restart. It completed.

The same operation ran to completion on the Iyonix first time – and in about half of the execution time.