05:37 <hramrach> aggi: yes, facts are facts, your interpretation of them is kind of cringe

05:39 <hramrach> I understand that if you want to self-bootstrap on an embedded board c++ compilers are a problem but that does not make them non-free, that's just delusional

05:40 <hramrach> most people have access to boards powerful enough to run the c++ compilers, one way or another (yes, I probably would not want tosel-host OLPC but that project kind of flopped, and if it did not it would probably have version of the hardware that could by now)

09:15 <apritzel> MoeIcenowy: can you check that the updated branch in your repo works on the V853, especially wdreset?

12:30 <aggi> hramrach: i do not want to interfere with the regular operation of this channel

12:31 <aggi> the reason to push and support c++ is not an excuse to lock-out free-software compilers compliant with C90/99

12:31 <aggi> i didn't say c++ and their compilers was non-free, i say those were utilized to lock-out particular free software

12:32 <apritzel> the Linux kernel just cannot be compiled with a pure just ANSI C compliant compiler, that's all

12:33 <aggi> Linux-Kernel, Uboot-loader, alot of _userspace_ components too

12:33 <apritzel> and there are reasons for that

12:33 <aggi> it was almost one year of work, to sanitize the _userspace_ again

13:41 <evgeny_boger> Hi, is there anyone here with dual-rank R40 (A40i/T3) board, such as Forlinx OKA40i?

13:47 <apritzel> MoeIcenowy: do you know if the T113 shares shares the same alleged limitations (no DSP, no DSP SRAM) with the D1s?

13:48 <hramrach> aggi: ok, so you want to run a softcore to be able to avoid any backdoor in fixed function silicon (and let's assume you have some free VHDL toolchain or can write one) and there is no programmable silicon that is reasonably fast to run these softcores at speeds that would make compiling c++ viable but compiler authors migrated to c++ for their code because it provides some

13:48 <hramrach> features they consider useful, and other code authors migrated to new compilers written in c++ because they in turn provide features that they consider useful for their code .. unfortunate for your use case, sure. Vendor lockin or making software non-free? Hardly.

13:48 <apritzel> MoeIcenowy: because on my MangoPi I see the DSP SRAM being there and mapped to the Cortex cores, and even the BROM apparently using the end of it for some FEL operation

13:50 <hramrach> I'm not saying that your use case is invalid but at the same time software that does not serve your use case can still be perfectly fine for other people doing other things, and even considered free software.

13:50 <aggi> hramrach: i fear there won't be long-term reliable supply of hardware available to run "free software", hence a free/opensource RISC SoC is crucial

13:51 <jakllsch> what good is the source if you can't turn it into a semiconductor cheaply?

13:52 <hramrach> yes, you still depend on the programmable silicon so if the fixed function hardware becomes non-free why do you assume the programmable one will magically not?

13:52 <aggi> yes, that's another problem, FPGA with opensource software-tooling available (Lattice, ECP5), operate at very low frequencies

13:52 <aggi> and the Altera/Xilinx ones are mostly non-free

13:53 <aggi> and this is very sad for everyone involved with free software

13:55 <MoeIcenowy> apritzel: T113 surely does not

13:55 <MoeIcenowy> its document shows DSP

13:55 <hramrach> Also I don't assume all hardware will become non-free. There is a risk that non-free hardware will become more common but the risk of all becoming non-free is pretty low, and likely only enabled by other more devastating problems

13:56 <jakllsch> yup

13:56 <aggi> at the level of Verilog/HDL all available hardware is non-free, including the developement tooling

13:57 <jakllsch> you know what we mean..

13:57 <apritzel> I don't really understand what "free hardware" has to do with "free software"? I am not sure there was ever any significant mainstream use of "free hardware", down to the gate level

13:58 <hramrach> "free stack"

13:58 <apritzel> and for all practical purposes the Allwinner D1 (with a "free" RISC-V core) is the same black box as the R528 to us

13:59 <MoeIcenowy> apritzel: C906 is not free

13:59 <aggi> GNU toolchain and LLVM, which are advertised as "free software", mostly are utilized as a dumpyard to support non-free undocumented hardware

13:59 <MoeIcenowy> it's openC906, which is a fixed configuration version of C906, that is free

13:59 <MoeIcenowy> and surely D1 is not using this configuration (it contains V)

14:00 <apritzel> that's what I mean, plus the fact that all the non-core peripherals are still the some bad and non-free design

14:01 <apritzel> AFAIK the Cortex cores in Allwinner SoC were the least of our problems. I am not sure what a "free core" gives you, practically, for a normal SoC

14:02 <apritzel> aggi: huh? what has the fact that practically all relevant computer hardware being non "free" in the FOSS sense has to do with GCC or other compilers?

14:03 <hramrach> GNU toolchain was developed on non-free, undocumented hardware, and it's what vast majority of people use today, anyway. So realistically aiming with a toolchain usablee today for something else does not make sense. Sure, aiming for having really free hardware is a worthy goal but when you don't have any that is practically usable you can't expect the world to target it with

14:03 <hramrach> every piece of software under the sun, even free software.

14:03 <apritzel> I was assuming that we have free software to run on people's hardware, whatever this is

14:05 <aggi> apritzel: the "free software" campaigning lures development manpower into non-free vendor-locked designs

14:05 <aggi> btw, European Space Agency invested into SPARC Leon

14:06 <apritzel> aggi: I am sorry, you lost me completely ...

14:06 <aggi> :(

14:07 <apritzel> aggi: I appreciate your efforts in tcc and maybe removing unnecessary GNUisms from existing software, but your rationale seems completely bonkers to me :-(

14:09 <apritzel> GCC is a cornerstone of the FOSS world, because it is completely free and allows to compile your code for *everything* out there, be it x86 or RISC-V or what-not

14:10 <hramrach> it's not vendor-locked design if your software requires some amount of computational power and only some vendors (which don't happen to produce free hardware for your definition of "free") provide enough power tu run it reasonably

14:10 <apritzel> and LLVM (and many other FOSS compilers out there) provide healthy competition

14:11 <apritzel> it's just not 1985 anymore, and things got *slightly* more complicated, in terms of hardware and software complexity

14:12 <apritzel> hramrach: yes

14:12 <hramrach> but yes, if you only trust softcores for which you have the whole hardware sources then it limits your software options, and if you claim software that cannot run reasonably on a sftcore "non-free" that will be a lot of it out there

14:13 <hramrach> but that's not how "non-free" is defined and how most people use it so please invent a new term for it

14:25 <aggi> apritzel: armv6j-hardfloat-linux-musleabihf compiled userspace works again, including python3.8

14:28 <aggi> if necessary, i can try to trace which "illegal instruction" it was, don't know how to do this.

14:53 <aggi> apritzel: with the updated kernel-config this is what showed up in dmesg

14:53 <aggi> 70.187455] "python" (435) uses deprecated CP15 Barrier instruction at 0xe6393230

15:56 <MoeIcenowy> apritzel: well for a long time we need some fork of GCC for AR100 ;-)

15:56 <MoeIcenowy> I mean, OpenRISC ;-)

15:57 <apritzel> MoeIcenowy: if there would have been a huge demand for it, then it would have been merged much earlier, I guess

16:01 <apritzel> aggi: well, there you have it: proper barrier insns were introduced in v7 only, and CP15 barriers were deprecated at the same time. So a v6 toolchain would use CP15 barriers, which need to be explicitly enabled on v8 cores, IIRC

16:03 <MoeIcenowy> apritzel: yes, this is what I met when trying to run a build targetting RPi1 on a ARMv8 machine (RockPro64 w/ RK3399)

16:05 <aggi> apritzel: don't know yet, if arm-tcc would emit such instructions too

16:05 <apritzel> there is SCTLR(_EL1).CP15BEN which controls the availability

16:05 <apritzel> aggi: probably not the compiler, but possibly some (inline) assembly

16:06 <aggi> thinking to silence kernel demsg about this, it's thousands of messages

16:06 <aggi> not a huge issue, gcc-4.7 and arm-tcc are just another sanity check

16:59 <apritzel> MoeIcenowy: thanks for the merge! I will check and try the A63 code on my A63 tablet later