chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<MoeIcenowy>
smaeul: how much RAM will be needed if we convert sunxi SPL to DM?
<smaeul>
depends on how much we convert, and if we use OF_PLATDATA and other hacks
<smaeul>
MoeIcenowy: I think we will have to do it anyway, unless we want to duplicate all PMIC code
<smaeul>
we need DM_PMIC for device tree probing of regulators, which we need for phandle references from the USB PHY, which we need to complete DM_GPIO conversion
<smaeul>
if we do not use DM_PMIC in the SPL, I don't know what to do
<smaeul>
in fact right now I am trying to get H6 booting with DM_SPL so I can see what the size is (but I am done for today)
<smaeul>
s/DM_SPL/SPL_DM/
cmeerw has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
warpme_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
jagan_ has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
jagan_ has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
Net147_ has quit []
Net147 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
<warpme_>
apritzel: sorry for late replay. I have sdd drive failure on my builder machine - so can't easily do checks you propose. i'll return to you asap when my build env. will be restored.
<apritzel>
warpme_: not needed, anymore, it looks like we are closing in on the issue
<apritzel>
warpme_: smaeul has sent a patch already, actually it looks like a compiler bug (introduced with GCC11, presumably)
<smaeul>
so should I resend the same patch with an updated commit mesage?
<smaeul>
unless maybe we can find a more targeted workaround
<apritzel>
smaeul: yeah, I think we should be using -mgeneral-regs-only regardless, it just sounds safer
<smaeul>
making `struct dram_para para` static avoids the initialization, but seems too magic
<jernej>
hm... since regression is already part of stable release, should we implement check in U-Boot build scripts?
<jernej>
there is also one of the older binutils release which fails to build U-Boot
<jernej>
but building improperly is worse
cnxsoft has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
<apritzel>
jernej: what check do you mean? Checking for GCC 11, explicitly?
<jernej>
apritzel: yes
<jernej>
but at the end, it will fail to build most, if not all, U-Boot releases with H6 support
<jernej>
so I guess best we can do, is to document this somewhere
<apritzel>
I don't think that's a good idea, since this will probably be fixed in an upcoming bugfix release, and it wouldn't help against older releases anyway
<apritzel>
I think smaeul's -mgeneral-regs-only is the right solution
<ndufresne>
montjoie: if you can get an ffmpeg binary that matches what jernej and cie uses on librecomputer, you could run fluster (https://github.com/fluendo/fluster), its not passing 100% but you can make sure the result is stable
<ndufresne>
(in reply to you 2w question, back from vacation :-D)
<jernej>
apritzel: well, I'm always for solution which fixes root cause, in this case gcc
<apritzel>
jernej: but how would GCC 11 detection fix the problem?
<jernej>
apritzel: you can fail build with informing user that it won't work
<apritzel>
but smaeul's patch would actually fix it, instead of leaving users in the dust
<jernej>
well, if you say use older (or newer) build, user would still know what to do, right?
<jernej>
s/build/gcc/
cnxsoft has quit []
<jernej>
apritzel: is there any benefit using -mgeneral-regs-only except for this issue workaround?
<jernej>
it generates slower code for some cases, right?
<apritzel>
jernej: effectively this is what's happening today already, I'd say
<karlp>
why is i ta problem anyway? it is compiling for the right cpu type, has athe fpu simply not been enabled or something?
<apritzel>
I mean we probably won't find NEON instructions in a U-Boot binary
<jernej>
karlp: see link with proposed fix
<apritzel>
it's just that GCC 11 got more wacky with its optimisations
<karlp>
which patch link? I understand that if it uses a neon instruction on a neon capable core, uboot gets upset? and the workaround is to tell the compiler to only use subset registers,
<karlp>
jsut turn on the fpu an dlet it be used?
<apritzel>
karlp: it's not NEON instructions that upset it
<apritzel>
it's an unaligned access, even though -mstrict-align is specified
<karlp>
well that would be a gcc bug then surely?
<apritzel>
exactly, like I said above ;-)
<karlp>
if it's unaligned access, it doesn't sound like "use general regs only" is a suitable fix
<jernej>
apritzel: in the past, binutils failed to link U-Boot and we didn't change ld files just because of that
<apritzel>
well, it fixes the problem, because the gcc bug seems to be in the (new) NEON optimisation code
<jernej>
I would say it's workaround, which is different than fix
<apritzel>
and I think allowing NEON is some kind of oversight, I am not sure we really want or need FP code in U-Boot
<apritzel>
jernej: yes, that's true
<apritzel>
we have -msoft-float for ARM, which kind of hints that this is the intention
<apritzel>
and architecturally NEON is optional, even in ARMv8, and you can configure a Cortex-A53 without FP
<apritzel>
so there could be cores which cannot execute NEON
<jernej>
is it? I don't think anyone assumes that...
<karlp>
if it's cmpiled with soft float, and it's using hw float ops, that's _also_ a gcc bug surely?
<apritzel>
I don't think soft-float applies to aarch64
<apritzel>
we have a shared Makefile for v7 and v8, so a lot of stuff gets mixed together there
<jernej>
neon is more than just FPU, right? vector math?
<karlp>
are we compiling with mfloat-abi=soft explicitly?
<apritzel>
yes, there is "floating point", which is the classic IEEE scalar FPU, and "Advanced SIMD", which is a vector unit, with separate (partly shared) registers and separate instructions
<apritzel>
karlp: in arch/arm/config.mk we have: $(call cc-option, -msoft-float)
<apritzel>
IIRC cc-option checks whether this option is available with the compiler, and ignores it otherwise
<jernej>
so imo vector instructions can still be used with -msoft-float
<apritzel>
just to make sure: aarch64 gcc does not recognise -msoft-float nor -mfloat-abi
<apritzel>
and "-march=armv8-a" includes "_
<apritzel>
and "-march=armv8-a" includes "+fp" and "+simd"
<apritzel>
and presumably -march=armv8-a is the default arch string baked into most GCC builds
<karlp>
gross, you need to explicitly turn things off with feature flags on aarch64
<karlp>
but armv8-32 bit is still on "classic" flags
<apritzel>
well, the expectation is that Linux runs on a CPU with FP
<apritzel>
and IIRC this was only fixed lately (to also support FP-less cores)
<apritzel>
hence the *default* GCC options are reasonably to include FP/SIMD
<apritzel>
but still vendors would be able to build a SoC without FP, for specific applications
<apritzel>
karlp: armv8-32 would be served by the 32-bit (v7) GCC anyway, which is a different target
<apritzel>
an aarch64-*-gcc cannot generate 32-bit code (in contrast to a x86-64 gcc, which can emit i386 code)
<karlp>
apritzel: yeah, but the "-march" is still just armv8a....
MangyDog has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
cmeerw has joined #linux-sunxi
chewitt has joined #linux-sunxi
JohnDoe_71Rus has quit []
hlauer has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
hlauer has quit [Read error: Connection reset by peer]