Problems building OMAP ROM

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

Sorry, I didn’t express myself adequately.

If ROOL created a zip archive instead of a tar/bz2 tarball, we wouldn’t have these problems, would we?

If ROOL created a zip archive instead of a tar/bz2 tarball, we wouldn’t have these problems, would we?

No we’d have a whole pile of new ones. Like WinZip not extracting empty directories and who knows what else.

[…] a whole pile of new ones.

Looking back now, there are some explanations in Self-extracting archives.

RE: Building standalone modules

I’ve not changed anything with my setup, and in all cases I’m sure it was from a clean boot-up. It seems necessary to run Builder with ‘Export headers’ selected before building standalone modules. Is this correct? Manually filetyping ‘PortableSA’ to &ffa, RMKilling and then RMLoading this gives an abort on data transfer.

When I have the modsqz error, ‘PortableSA’ is created in ‘o.CortexA8’. Sometimes there is also a ‘Portable’ file of the same size – is this the result of the complete build I did previously? I get the same abort on data transfer when using this.

Anyway, if I rename ‘PortableSA’ to ‘PortableSAerr’, a re-run ‘MkSA’, a new ‘PortableSA’ file is generated and the error repeated. If I retain ‘PortableSA’ and re-run ‘MkSA’ the filestamp isn’t changed but I don’t get the error.

It seems necessary to run Builder with ‘Export headers’ selected before building standalone modules. Is this correct?

Not entirely. All you really need to do is select the right build folder & product. This then causes the corresponding env file to be run, which will set up all the system variables and things needed by the build system.

Manually filetyping ‘PortableSA’ to &ffa, RMKilling and then RMLoading this gives an abort on data transfer.

Which PortableSA? The ‘o’ folder contains object files; you won’t be able to run them directly, no matter what you set the filetype to. The ‘rm’ folder contains the linked module, whether modsqz has successfully squeezed it or not. The files in the ‘rm’ folder should always have the correct filetype (unless ‘link’ failed, but that doesn’t seem to be the case here)

Sometimes there is also a ‘Portable’ file of the same size – is this the result of the complete build I did previously?

Yes.

Anyway, if I rename ‘PortableSA’ to ‘PortableSAerr’, a re-run ‘MkSA’, a new ‘PortableSA’ file is generated and the error repeated. If I retain ‘PortableSA’ and re-run ‘MkSA’ the filestamp isn’t changed but I don’t get the error.

When I get a chance I’ll try recreating the modsqz error myself. The fact that it works fine on my Iyonix suggests that it might be something SCSI/beagleboard specific.

However, as long as a valid PortableSA module gets created in rm.CortexA8, there shouldn’t be anything stopping you from softloading that module, even if modsqz produces an error.

Which PortableSA? The ‘o’ folder contains object files; you won’t be able to run them directly, no matter what you set the filetype to. The ‘rm’ folder contains the linked module, whether modsqz has successfully squeezed it or not.

Sorry – that explains that one!

However, as long as a valid PortableSA module gets created in rm.CortexA8, there shouldn’t be anything stopping you from softloading that module, even if modsqz produces an error.

Of course. Note – I did start reading the tools manual but it advised reading the PRM section on modules before ‘playing’. So I got out the PRMs but haven’t even skimmed through yet. I intend to add info to the wiki later, for the benefit of other noobs.

I intend to add info to the wiki later, for the benefit of other noobs.

Remember that there’s already quite a bit of info in the technical notes section, so try and work with the existing docs where it makes sense to do so.

Thinking about it, it would probably make sense if !Builder and the other tools (e.g. !Prepare) had their Help files updated to point to the relevant documentation on the wiki.

[…] try and work with the existing docs where it makes sense to do so.

I agree that’d be a good idea.

[…] if !Builder and the other tools (e.g. !Prepare) had their Help files updated to point to the relevant documentation on the wiki.

Are they going to be added to Ancillary downloads? If so, should Builder perhaps be moved to Software information: Builder? I don’t think Prepare is on the wiki just yet.

Are they going to be added to Ancillary downloads?

I’d guess not, since Builder and Prepare are rather useless as standalone programs, and you should receive a copy of them in any source code you download anyway (whether downloading source tarballs or checking out via CVS)