Usually when I look for clarifications about some ARM internals I get the word "Confusion" attached to the results. At least I'm confident now that it's not something wrong with me :)

Finally I got some good explanation about the "silly" terminology - ARM, Thumb(v1) and Tumbv2:
https://stackoverflow.com/questions/...ions-confusion

It looks like Raspberry are using thumb (maybe for compatibility) for their binaries:

readelf -A /opt/vc/bin/vcgencmd
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM1176JZF-S"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_HardFP_use: Deprecated
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

I maybe should recompile my crosstools-ng generated cross-compiler with - thumb instead of arm instruction set. Another 5 hours of Pi2B grill.

(At least I managed to get rid (evaporated) of the horrible chemicals stink (reported in the Raspberry Pi forums) out of this board. It's from the U.S. (distributed by RS), there were no non-stinking Pi2B available in Europe anymore (distributed through Element14) as I started to stash some.)

By comparing the manual unfinished gcc 7.2.0 build from my first attempt with the result from crostool-ng I learned that both compilers have the:
mvectorize-with-neon-quad [enabled]

And I didn't ask specifically for it, nor could I find something in the crostool-ng configuration where I could enable/disable this optimization.
I noticed that this NEON optimization was also enabled by default in the new gcc 7.2.0 package that came for SlackARM - current HF and was wondering if it was deliberately switched on or just unintentional.
It looks like the new gcc 7.2.0 comes with it enabled by default, thus, my cross-compiler, the one generated with crostool-ng is OK.

On the Thumbv2 issue, I'm guessing that the compiler chose it deliberately because I was linking my binary with the system libs and not with the ones from the compiler's sysroot. These system libs are all Thumbv2.
ldd tinymembench
linux-vdso.so.1 (0x7eda5000)
libm.so.6 => /lib/libm.so.6 (0x76f16000)
libc.so.6 => /lib/libc.so.6 (0x76db1000)
/lib/ld-linux-armhf.so.3 (0x54b6b000)

readelf -A /lib/libm.so.6
Attribute Section: aeabi
File Attributes
Tag_THUMB_ISA_use: Thumb-2

Meanwhile I started a new cross-compiler compilation and chose to tune the cross-compiler solely for the CPU in Pi0. This will help me compile the Slack without adding the specific CFLAGS all the time:
- In Target options menu (crostools-ng interface) I filled the following in:
(armv6zk) Architecture level
(arm1176jzf-s) Tune for CPU
(vfp) Use specific FPU

Will start compiling the packages needed for the armv6 HF minirootfs once I get some more time.

hint: get the arm6 compiled *binas rootfs's and try run the
[cpde]readelf -A /lib/libm.so.6[/code]
and check if (and what) they do?
Further, afaik, Debian is 'bootstraped' from its sources each time?

just reminding? (HTH)

@SCerovec

Thanks for the hint! armv6 HF libs are nowhere available and must be compiled from the scratch. I cannot start with the ones available armv7 HF in SlackARM - current or armv6 SF in SlackARM 14.2 . Stealing some from Debian& co it's against everything I'd like to achieve.
Actually I was following AlienBOB's scripts (parts of) in order to get the first bootsrap - that's the libs I'll need in my minirootfs:
http://taper.alienbase.nl/mirrors/alienarm/bootstrap/

However, as described above, I don't have the necessary tools (compiler) to build armv6 HF VPF Thumb-1 binaries ATM . And you cannot build anything without tools, can you?

After spending a considerable amount of time with building a GNU gcc based toolchain to generate armv6 HardFloat code, I came to no results and I'm thereby quitting this SlackARM HardFloat port for armv6 struggle or "endeavor".
I might qualify now with the ones drmozes mentioned in his first post:
"However, porting Slackware is no trivial task - it's a *lot* of work. A few people have started and have not continued."
https://www.linuxquestions.org/quest...7/#post5213236

At least I've documented my struggle and the issues I came across, finally not being able to build an actual toolchain in order to help me getting started.

There might be possible solutions for getting this done, I didn't want to take those paths, and I'll enumerate 3 of them:
1. Try to build a toolchain based on the Linaro compiler and go through AlienBOB's scripts (well, part of them) on a SlackARM-current HF powered Pi2/3 and use SlackARM-current source code. However, I'm not sure the SlackARM-current source code and its patches will compile without issues under Linaro.
2. Start the compilation on an already armv6 HardFloat enabled Linux distribution (there are some), again, by following AlienBOB's scripts. This approach might be better positioned for success, but I consider it dirty. No disrespect towards other distros, not at all, but just describing the approach!
3. Try to use older GNU gcc releases (something from 4-5 years ago) on a SlackARM-current HF powered Pi2/3 and build a toolchain/crosscompiler with them, then follow AlienBOB's scripts. Here you might also have issues with the SlackARM-current source code and its patches.

In my opinion the GNU gcc is not really well/completely documented and crosstool-ng while helping a lot is also not really controllable / fine tunable. The GNU gcc latest releases look like forgetting about armv6 and focusing more on the newer ARM architectures and the issue I got into has no solution apparently:
Issue:
sorry, unimplemented: Thumb-1 hard-float VFP ABI

Some research:
https://stackoverflow.com/questions/...with-gnueabihf
https://www.raspberrypi.org/forums/v...hp?f=33&t=8758
https://forums.gentoo.org/viewtopic-...2-start-0.html
https://patchwork.ozlabs.org/patch/539155/
https://sourceware.org/ml/newlib/2013/msg00124.html

I'd also like to mention that I was trying to build a GNU gcc crosscompiler with the help of the crostool-ng (latest git) and by switching the Default instruction set mode from arm to thumb I got into build crash:
Target Architecture (arm) --->
Default instruction set mode (arm) --->
to:
Default instruction set mode (thumb) --->

By keeping my promise that I'll not quit Slackware, I just quit using the Raspberry Pi0 and will stay away from armv6 devices form now on. They're already obsolete and not marketed anymore (apart from some weirdos like the Pi0).

armv6 is dead! Long live armv6! :)

1. Kind thanks for the report
2. Condolences for the Pi0 and the demise of arm6 in the gcc (no regression in open source? how much longer?)
3. Lately I notice there will always be just an "window" of hardware supported by the free software, and there already are some trends that seem to try to squeeze it?

OTOH:
When I mentioned to "peek" to the other distros, I meant to peek to their build-scripts that "bootstrap" the GCC to cross compile, but as You seem to have found already, one could be forced to "time travel" into the "era" or the armv6 being "latest and greatest"?

-> Namely Arch and Debian proud them selves as the "bootstrap from source baby - each time" distros? Or am I dead wrong here?

One way or the other, dead lie the "lesser" pies :^[ (maybe the "Pi" pun, in the 1st place, was the intention to stress to "get them while they hot"?)

Exactly - in commerce it's budget vs demand and profit, and open source it's interest, skills and time.
I don't think armv6 ever was the latest and greatest - the distributions went from armv5 soft float -> armv7 hard float.
I don't recall ever seeing an armv6 machine anywhere until armv7 was already wide spread, and the Raspberry Pi came along sporting an older CPU.

I have not looked at bootstrapping from scratch (not that you ever boot strap from scratch - you're always using previous work) for years; but when I did back in 2003, IIRC Debian was built as was Slackware - lots of hacking, glue, string until you had a system upon which the whole package set be re-built. I don't want to think how many times I had to power down my StrongARM RiscPC and my x86 PC so that I could move the hard disk and try booting my new set of packages I'd just cross compiled. That was at the time when Emdebian was nacent, whose goal was to cross compile packages rather than build natively (as Debian does). I don't know if the work from Emdebian fed back into the main tree, but it probably did to some degree since the people involved were the heavy lifters in the Debian ARM port.

@SCerovec & @drmozes
During my work I was stumbling (internet posts) upon a lot of failed tries to get HF code for armv6 under the GNU toolchain and my impression is that this toolchain was never really able to produce such code, not without a lot of tweaking and specific configure scripts fine tuning for all its components during the toolchain build, and that explains a lot about the armv6 HF support, including Slack 14.2. It looks that this is where Linaro came across and was widely adopted in the ARM world.

@drmozes
Please do not regard the Raspberry Pi Foundation as part of the "normal" commercial realm - it's a Foundation with some specific educational goals (vision/mission), at least in theory. What they started with was selling Broadcom's already obsolete technology bundled in a cheapest possible/obtainable board. I wasn't considering buying those first boards (Pi 1) because they were pretty useless performance-wise and only opted for the Pi2B once it got released. What is happening now with these 5/10 GBP for every 10 pennies worth iteration / improvement is another story and a really interesting development. But then a "Foundation" must also grow somehow and the toys they're selling are good quality and stable, good for some SOHO projects.
As stated in another post, there are other interesting "Server Grade" ARM developments and those should be the focus for a good Linux distro.
On your "lots of hacking, glue, string until you had a system upon which the whole package set be re-built" statement - indeed, that's what scared me, not the packages compilation per se. I was considering a cross-compilation from the very beginning, and you need to build at least the system some libs from the a directory (aaa_elflibs - already compiled binaries in the source archive) and the toolchain from scratch. As stated in my last report - failure, I couldn't use anything from both SlackARM 14.2 / SlackARM - current to start with.

On armv6 (armv7 too?) system build/compilation even Google, with their 100K engineers army, are not supporting HF:
https://developer.android.com/ndk/guides/abis.html

So, in the end,
anyone giving a shot at this: Should Linaro's tool chain fail too (<- last stone unturned) - don't bother for armv6 HF?
The only unknown is which release of the tool chain is most likely to be "the winner"?

@abga and @drmozes
kind thanks for the insight of the arduous process of obtaining an "alien arch" (cross compiled) rootfs able to compile further.

The question is, even once thru with a running rootfs and an running GCC for armv6HF abi - is that uncharted territory?

Further,
is GCC the only free+open option for producing an GNU-like rootfs with an compiler?

@SCerovec
I got some spare time the other day and went through a "last try" to obtain an armv6 HF toolchain on a Slack 14.12 x86-64 powered Intel i3 spare system. I was using crosstool-ng 1.2.30 which has an already configured target called armv6-rpi-linux-gnueabi that defaults on Linaro!
https://crosstool-ng.github.io/docs/configuration/
However, the build crashed somewhere towards the end with a pretty common (found on other forums) error and I just rm -rf my work-directory/ :)
Now, I cannot compare my experience in toolchain building with the folks at crostool-ng and the fact that they choose Linaro over GNU for their armv6-HF build tells me that they might have had themselves issues with the GNU stuff before.

On your other question, as mentioned in the previous posts, AlienBob has already documented the Slack ARM build process and has some useful scripts in place, still available. Therefore it's not that much of an uncharted territory:
https://alien.slackbook.org/blog/armport/
http://taper.alienbase.nl/mirrors/alienarm/bootstrap/
But then drmozes mentioned that AlienBob got SoftFloat results with his approach:
https://www.linuxquestions.org/quest...6/#post5753195
I think, once you have a working armv6 HF toolchain, if any, you really need to pay attention how you generate the code - that's by using a sysroot, not linking the resulted binaries to your already in place system libs (which might be SoftFloat or a different arm architecture (armv7)) and pay attention to the --build= / --host= / --target= compiler flags.

sndwvs had recently obtained an aarch64 "alien" port and he might be able to provide some help with the toolchain / build process, if he wishes to.

As for me, I only have this pi0 that I got as a present and by considering the time(effort)/money efficiency ratio I'd rather spend 25EUR on an armv7 well performing board instead of wasting more time with this pretty useless pi0-armv6. Besides, pi0 boards are very hard to get - limited availability/production/faulty chips? from the previous overproduction.

Kindest thanks for the report and references (AlienBOB has amassed quite valuable stuff re Slackware bits and bolts :) )

I hope the time spent will be of good use for the ones that follow up?

:hattip:

I plan to take a bite or two when time permits, will report the outcome.

edit:
http://porteus-arm.googlecode.com/fi...-13-4-5.tar.xz
is this ^ armv6 hard float rootfs? O_o

I haven't looked much at the Linaro toolchain, but as far as I know, it includes updates and/or features for new ARM systems -- which eventually feed in to the upstream for gcc.
Personally I would not build with the Linaro toolchain for the OS because unless its usage is wide spread, you'll eventually arrive at problems that nobody else has; or if they did have them, they fixed them privately.
This is why I still use the Debian patch set for gcc. At least if there are problems, usually Debian also found them first and fixed it.

@SCerovec

I'm always documenting my efforts (even privately), work without documentation has no value for me, whatsoever. I'm happy that I was able to help you & maybe others who would like to follow up on where I left. I'd suggest to focus on obtaining an armv6 HF (able to generate) toolchain first, regardless of the platform. As drmozes suggested, stick with GNU and maybe patch it with the Debian patches from the SlackBuild. Or, go the dirty way, try Gentoo if you have a Pi1 with Ethernet. I tried it on my pi0 and I couldn't get the WiFi connected with the minimal (no kernel modules/ WiFi utilities, etc) rootfs that I was provided with from their download repo - I just dumped it. pi0 is not supported by Gentoo.

On Porteus - the link you provided is not working and on their forum I learned that they also went through my experience, but some 4 years ago. They are thanking drmozes for the support and as far as I can understand there is no armv6 HF port produced and the project looks stopped/forgotten ATM:
https://forum.porteus.org/viewtopic.php?f=112&t=1995


@drmozes
Thanks for the confirmation, I was reluctant to switch to Linaro exactly because of what you've described.

:/
bit rot at it's worst :-J