ARMv7 rebuild

[pepedog]

Trimslice, I was running v7 alarm without the nv drivers and was quite happy with that, hdmi/sound etc not that important to me, I see Mike had posted the PKGBUILD.

[kmihelich]

Apparently SMP is broken. The "solution" is.. hey.. you only need one core of our stripped down Cortex-A9, deal with it. The plan is, tentatively, get stuff mainlined a few versions down from now. In contrast with TI, they're going backward, and right now I really have a whole pile of other package issues to deal with than a busted kernel. I can do a mainline version for tegra, but the TrimSlice will be missing a lot of functionality.. USB most notably.

[pepedog]

I thought I was seeing things about the SMP, but without any kind of hard float system, I can't experiment myself.
I assume this issue applies to soft float also?

[kmihelich]

Yeah, it's ABI-agnostic. You should be able to use a soft kernel to boot into the new OMAP rootfs. Nothing with the kernel is dynamically linked (how could it be) so you should be able to throw in the /lib/modules directory and go. Maybe you could figure out a good kernel PKGBUILD to use in the meantime? It's hard for me to develop for a device I don't own and can experiment on.

[pepedog]

I found out why it wouldn't compile, literally a patch that changes just one letter, placed files in my bunghole (inc compiled kernel and headers)
http://myplugbox.com/bunghole/ts/
PKGBUILD only changes is patch filed added, MD5's, and patch command
Soooo,
how can I tell if this is a hard float kernel, print some environment thing?

[kmihelich]

Like I mentioned in the TS forum, you should be able to do an objdump on the uImage. When I get home I can figure out a working command if you don't.

[pepedog]

In makepkg.conf CFLAG includes -mfpu=vfpv3-d16-O2, trimslice don't like that.
Another poster vgrade of meego also suggests -mno-thumb
What do you think?

[kmihelich]

You can add -mno-thumb if that maybe flips a flag that makes it all work. GCC isn't compiled with thumb interworking, so for our toolchain it should be a non-issue. I don't use thumb because it's been shown in multiple cases to inflate binary size and make the application slower. Its best use is in tinier processors like the v5 or Cortex-M3, where with basic filesystem components and custom real-time applications that people use those processor for, you can decrease code size and speak sort of more "natively" to the processor. With A8 and A9 processors, others have found it reverses those effects, especially with the desktop- and server-oriented applications we use on them.

You'll still need to specify -mfloat-abi=hard -mfpu=vfpv3-d16, since this says hard float, and use the lowest common denominator VFP unit for v7, which is the Tegra's vfpv3-d16. vfpv3 implies vfpv3-d32 (16 additional registers), which is available in OMAP. But for OMAP, I'll be going with NEON for those instances anyway, which implies vfpv3.

I'd say try a different optimization level, maybe -O1. I've already run into instances with GCC 4.6 where -O2 breaks builds, mesa being one that I can think of offhand. You could even do just -Os for only size optimization. We're not flashing to NAND, so size isn't a huge consideration. Modularizing stuff that isn't onboard and is more of an accessory or peripheral, you can bring down the final uImage size as well. I did mass modularization with v5 recently, which brought uImage from 2.1MB to 1.5MB.

[pepedog]

Thanks so much for that, do appreciate your time.
Now I understand, there was no space before -O2, I shall separate -mfpu=vfpv3-d16-O2 and mourn that I do not have neon

[kmihelich]

Woops, that would be my bad on that one. PKGBUILD for pacman where I set makepkg.conf defaults for v7, I left out the required trailing space which smashed those two. I'll get that fixed before hopefully more of the same pops up.