moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
JohnDoe_71Rus has quit []
aggi has quit [Quit: back soon]
apritzel has joined #linux-sunxi
hentai has joined #linux-sunxi
aggi has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
arti has quit [Ping timeout: 480 seconds]
arti has joined #linux-sunxi
arti has quit [Ping timeout: 480 seconds]
arti has joined #linux-sunxi
aggi has quit [Quit: gn]
aggi has joined #linux-sunxi
bauen1 has joined #linux-sunxi
ftg has joined #linux-sunxi
<aggi>
is there any armv6 instruction from -mtune=arm1176jzf-s (RPI1) which a cortex-a53/armv8a/rk3328 couldn't process?
<aggi>
compiled python for CTARGET=armv6j-hardfloat-linux-musleabihf
<aggi>
and $ python errors with "Illegal instruction" then
<aggi>
otherwise, the entire userspace compiled runs flawlessly so far, except python-3.8
<apritzel>
aggi: -mtune should not generate incompatible instructions, it just optimises. -march does, so that value would count
<aggi>
apritzel: for the sake of simplicity i picked the one from RPI1 -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s
<jakllsch>
ARMv8-A doesn't even guarantee aarch32 execution ability
<aggi>
the final python binary/libs show the correct tagging vfpv2/armv6zk; can't rule out a flaw inside cross-compilation with absolute certainty
<jakllsch>
aarch64 and aarch32 are different instruction sets
<aggi>
well, the entire userspace boots/runs flawlessly, except python
<jakllsch>
true, it's often available
<apritzel>
jakllsch: true, but this is about an Cortex-A53, running in AArch32 already, not generic ARMv8
<apritzel>
and Cortex-A53 supports both instruction sets in all exception levels
<aggi>
there is reasons i want to emit aarch32 binaries, as armv6/vfp2, because this is what arm-tcc emits, and i want to keep this compatible/interoperable
<apritzel>
there are some deprecated ARMv6 instructions, which need special enablement in some sysregs on an A53, IIRC
<aggi>
and cortex-a53 is what i got for testing, which does run armv6 emitted by both arm-tcc and gcc-4.7 just fine - except python
<apritzel>
aggi: check "Emulate deprecated/obsolete ARMv8 instructions" in an arm64 kernel Kconfig
<apritzel>
there is SWP, cp15 barriers, and the setend instructions
<aggi>
since i assumed VFP-3 was backwards compatible with VFPv2
<apritzel>
aggi: there is CONFIG_SWP_EMULATE for an arm(32) kernel, if SWP is the problem
<aggi>
apritzel: already unpacking kernel
<apritzel>
aggi: wouldn't need to, just use link to the Kconfig file above, that has some explanation
<aggi>
the aarch64 kernel here had CONFIG_SWP_EMULATE=N ; which was NO problem with armv7 userspace, chances are with armv6/vfpv2 it is
<aggi>
apritzel: i'll test this tomorrow again. thanks for the quick answer.
<apritzel>
yeah, SWP was already deprecated in v6, not sure it would be still emitted
<aggi>
i was using gcc-4.7 to emit armv6/vfpv2 binaries
<apritzel>
do you have a core dump or trace of the Illegal instruction? You could scan an objdump of the binary to see if any of the incriminating insns are in there
<aggi>
apritzel: nope, no coredump, disabled
<apritzel>
ulimit -c unlimited
<aggi>
i'll recompile kernel tomorrow, will take an hour or two, i'll notify if the problem is solved
<apritzel>
does dmesg contain some info about the trapped instruction?
<aggi>
no
<aggi>
i did strace the python binary call, last call seen was getrandom(), and then errored out
<aggi>
apritzel: i it is helpful or of interest to @arm.com i can compile one or another kernel variant with debugging/coredump support too
<aggi>
i'll report tomorrow
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<apritzel>
aggi: this has nothing to do with arm.com, there we are at ARMv9.2 already ;-)
<aggi>
apritzel: i would rather be curious about some armv4 or similar, if the Verilog/HDL were available for an FPGA softcore SoC deployment
<aggi>
although, arm-tcc couldn't emit for this either
<aggi>
aarch64 is, not so nice, because, the compilers/toolchain (written in c++, slow, inefficient, when compiling on embedded as i do)
<aggi>
with aarch64 (or whenever this was introduced), i am not particularly excited about the ATF/PSCI, as another one
<apritzel>
aggi: to be crystal clear: I totally disagree with your "C++ is evil and un-free" motivation, and crying "vendor-lockin" is honestly close to an insult to all FOSS compiler engineers out there
<aggi>
i am not willing to dispute over the interpretation of facts, yet facts are facts
<apritzel>
and newer Arm Ltd. cores start to drop support for AArch32 even in EL0, so 32-bit clearly has no future
<apritzel>
(for Linux)
<aggi>
i began testing aarch32, because this is what gcc-4.7 could emit (the last compiler/toolchain i am willing to accept)
<aggi>
i won't accept llvm/clang either, for the particular use-case of mine
<aggi>
with tinycc, arm64-tcc ASM support seems absent still (tcc got an assembler on board), hence i continued with aarch32 and arm-tcc
<aggi>
and neither arm-tcc nor arm64-tcc could compiler linux kernel yet (and a bunch of other important components)