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
<rm_> no, it is the environment after all
<rm_> copying one specific SD card around gives more RAM to whichever board boots it
<rm_> but starting from a zeroed SD and using whatever u-boot version, gets less RAM
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
moteen has joined #linux-sunxi
macromorgan has quit [Quit: Leaving]
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
cnxsoft has quit []
macromorgan has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
sunshavi has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
hlauer has joined #linux-sunxi
Danct12 has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
ftg has joined #linux-sunxi
moteen 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]
apritzel_ has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<gamiee> V853 dev board on Aliexpress https://a.aliexpress.com/_mOV8q5M
ftg has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
aggi has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
moteen 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]
evgeny_boger has joined #linux-sunxi
ftg has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
evgeny_boger1 has quit [Read error: Connection reset by peer]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi_ has left #linux-sunxi [#linux-sunxi]
aggi is now known as Guest6081
aggi has joined #linux-sunxi
Guest6081 has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
<aggi> argh..
<aggi> not important, just to let you know
<aggi> integrating tinycc compiler CC=arm-tcc LD=arm-tcc ...
evgeny_boger has quit [Ping timeout: 480 seconds]
<aggi> and now i see, the armv7 (EABI5) profile chosen with gcc doesn't match arm-tcc emitted EABI4 (armv6)
<aggi> got a _userspace_ package set, which i wiped all c++ dependencies from, ~700 builds verified against gcc-4.7/c-only
<aggi> and, with arm-tcc 320/700 build succeeded already
<aggi> ideally, it will be possible to compile linux kernel with arm-tcc/arm64-tcc one day
<aggi> and with uboot loader there will be some severe issues too, hooking into arm(64)-tcc
<mnemoc> libv: around?
<aggi> alltogether, arm-tcc support is decent, including armv6 hardfloat (didn't test softfloat yet which it supports too)
<aggi> it's alot of work still, to fully stabilize an arm(64)-tcc toolchain for _userspace_; kernel and uboot are another milestone open for discussion elsewhere
<aggi> i'll downgrade the profile to armv6-harfloat (certainly good enough with arm-tcc) and see what else passes then
<aggi> the "fun" poject isn't limited to aarch32/64, although i test with aarch32 first
<aggi> hence if there is any interest in seeing an arm(64)-tcc toolchain supported just let me know
<mnemoc> libv, turl: maxima is having troubles according to CF so we need to resume the migration
moteen has quit [Remote host closed the connection]
cnxsoft1 has quit []
<aggi> if i had known, i had stabilized the gcc-4.7 aarch32 toolchain for EABI4 first, not EABI5
<aggi> won't be difficult, to roll-back aarch32 to a armv6/hardfloat toolchain/gcc-cross-compiler, since it is compatible with arm-tcc eabi4
paulk-bis has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
hlauer has quit [Ping timeout: 480 seconds]
sunshavi has quit [Ping timeout: 480 seconds]
moteen 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]
moteen has joined #linux-sunxi
sunshavi has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
aggi has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit []
moteen_ has quit [Remote host closed the connection]
moteen 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]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
paulk-bis has joined #linux-sunxi
<aggi> does -march=armv6j imply EABI version 4?
<aggi> asking, because arm-tcc emits vfpv2/armv6/eabi4 and i want to keep this compatible with whatever gcc-4.7 has to emit
apritzel has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<aggi> greetings apritzel
<aggi> chances are you missed some question
<aggi> does -march=armv6j imply EABI version 4?
<aggi> asking, because arm-tcc emits vfpv2/armv6/eabi4 and i want to keep this compatible with whatever gcc-4.7 has to emit
<apritzel> aggi: I am not particularly interested in archaeology, but I would say that is independent and something to be configured as defaults when building the toolchain
<aggi> apritzel: archeology?
<aggi> i am on latest git HEAD of tinycc compiler
<aggi> and the binaries it emits run just fine on some recent cortex a53 armv8a cpu
<aggi> the reason i want to keep this compatible/interoperatble is this only:
<aggi> i got a c-only toolchain system profile here (compiled with gcc-4.7 for armv7 up until recently), and now swap GCC against tinycc
<aggi> tinycc already succeeded with 320/700 ebuilds of the _userspace_ parts, and i expect some blockers to retain gcc/binutils with
<aggi> and to mix compiler/linker of gcc and tinycc while testing i hit some other iregularities
<aggi> such as, how to tell GCC to emit exaclty this: armv6/vfpv2/eabi4; to remain stable and safe
<karlp> what's the goal here, using gcc 4.7, or using tiny cc?
moteen has joined #linux-sunxi
<aggi> the goal is: removal of all c++ (hence gcc-4.7 which was the last clean GNU toolchain concerning this)
<aggi> then next, wipe GNU toolchain and replace as much as possible with arm-tcc, in _userspace_ first, because reasons
<aggi> and it seems, arm-tcc considered some particular abi stable, so i want to keep it at this with GCC too
<aggi> and i had seen whan ebuild fail, dev-libs/libffi complaining about ABI mismatches, hence i want downgrade CBUILD to armv6 first
<aggi> an
<aggi> i'll simply test this, just sad, because the armv7 variant is stablized for almost one year now, and i didn't expect to hit yet another brickwall
moteen has quit [Ping timeout: 480 seconds]
<aggi> -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard should do, it's the raspberry1 i think, which should be safe as far as vfpv2 instructions are concerned (which arm-tcc got support for)
<aggi> not sure, if this could hit something not supported by armv8a/cortex-a53; i'll know tomorrow morning
<aggi> some talking about this, related to the EABI version: https://github.com/crosstool-ng/crosstool-ng/issues/1548
<aggi> seems it is not possible to enforce this easily, to avoid any side effects elsewhere
<aggi> i'll know soon enough
<aggi> weird... gcc -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard test.c
<aggi> still reports this: Tag_CPU_name: "7-A" ... Tag_FP_arch: VFPv3
<aggi> with arm-tcc: Tag_CPU_name: "6" ... Tag_FP_arch: VFPv2 etc.
<aggi> could be, the tagging is informational only, and code emitted doesn't contain imcompatible vfp instructions (just an example)
rajkosto has joined #linux-sunxi
rajkosto has quit []
vagrantc has quit [Quit: leaving]
<aggi> same with -march=armv5 Tag_CPU_name is still 7-A
<aggi> march=armv4, test binary reports vfpv3, impossible; either the reporting is wrong, or potentiall vfpv3 is emitted even when not desired, or both
<aggi> all i know, when compiling libffi (required by python3), the build complained about some ABI mismatch
<aggi> libffi compiled with arm-tcc
<aggi> maybe it was using the libc.so from CBUILD, so given i am not concerned about a clean cross-compile yet, i want to tick down CBUILD to armv6/vfpv2/eabi4
<aggi> which seems impossible, with gcc/binutils i got
<aggi> strangely, hundreds of builds succeeded already, with arm-tcc, including a /bin/bash, and other monsters
<aggi> karlp: the goal is, i want to compile/link/asm _everything_ with tinycc, kernel, libc, uboot-loader, and of cause the entire userspace
<aggi> given the situation surrounding linux-kernel (vendor-locked against GCC and LLVM, both compilers written in c++ nowadays), uboot loader got some problematic dependency graph against python-swig (written in c++)
<aggi> i began with userspace
<aggi> and arm-tcc