ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
montjoie_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
juri__ has quit [Ping timeout: 480 seconds]
juri_ has joined #linux-sunxi
moteen has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
ftg has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
juri__ has joined #linux-sunxi
juri_ has quit [Read error: Connection reset by peer]
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
szemzoa has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
bauen1 has quit [Quit: leaving]
gnarface has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
gnarface has joined #linux-sunxi
bauen1 has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
cnxsoft has quit []
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
moteen_ has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
anarsoul has quit [Quit: ZNC 1.8.2 - https://znc.in]
anarsoul has joined #linux-sunxi
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> moment... takes some time
<aggi> almost forgot -mfloat-abi=hard
<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)
<aggi> *compile linux kernel
<aggi> gn
vagrantc has quit [Quit: leaving]