search

SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
3.02k stars 1.23k forks source link

Armadaxp toolchain incorrectly using vfpv3-d16 flag? #5283

Open ta264 opened 2 years ago

ta264 commented 2 years ago

Is this a new Bug?

Package Name

syno-armadaxp

Package Version

All

Device Model

DS414

Device Architecture

ARMv7

Firmware Version

7.0.1

What happened?

The toolchain for armadaxp is setting -mfpu=vfpv3-d16.

https://github.com/SynoCommunity/spksrc/blob/a6da5d8e312b3755c157ce0ff248289a9a63a773/toolchain/syno-armadaxp-7.0/Makefile#L12

I think this is incorrect based on the output of 

$ cat /proc/cpuinfo
Processor       : Marvell PJ4Bv7 Processor rev 2 (v7l)
processor       : 0
BogoMIPS        : 1332.01

processor       : 1
BogoMIPS        : 1332.01

Features        : swp half thumb fastmult vfp edsp vfpv3 tls
CPU implementer : 0x56
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0x584
CPU revision    : 2

Hardware        : Marvell Armada XP Development Board
Revision        : 0000
Serial          : 0000000000000000

Note it reports vfpv3 but not vfpv3d16.

Compare with the output on an Armada370 DS115j:

# cat /proc/cpuinfo
Processor       : Marvell PJ4Bv7 Processor rev 1 (v7l)
BogoMIPS        : 795.44
Features        : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls
CPU implementer : 0x56
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0x581
CPU revision    : 1

Hardware        : Marvell Armada-370
Revision        : 0000
Serial          : 0000000000000000

This does report vfpv3d16 and so needs the -mfpu=vfpv3-d16 flag.

I think the armadaxp toolchains should be using -mfpu=vfpv3 like armada375 does: https://github.com/SynoCommunity/spksrc/blob/a6da5d8e312b3755c157ce0ff248289a9a63a773/toolchain/syno-armada375-7.0/Makefile#L12

This is relevant to .NET apps, which currently required support for full vfpv3. Currently I believe this is only causing issues for armada370. There have been intermittent reports of .NET apps failing on armadaxp, alpine and alpine4k. I believe these issues are all due to outdated libraries on DSM and can be worked around via a chroot style wrapper.

I think I have a working Radarr for CPUs that only support vfpv3-d16 based on a custom .NET build and I am trying to work out which architectures this needs to be used for.

Reproduction steps

See https://github.com/SynoCommunity/spksrc/blob/a6da5d8e312b3755c157ce0ff248289a9a63a773/toolchain/syno-armadaxp-7.0/Makefile#L12

Install Log

N/A

Service Log

No response

Other Logs

No response

mreid-tt commented 1 year ago

@hgy59, I came across this older issue and I was wondering of it's current applicability and impact on the dotnet-based packages.

EDIT: From previous reports it doesn't seem to affect persons running Sonarr v4 and Radarr on armadaxp archs (https://github.com/SynoCommunity/spksrc/issues/5574#issuecomment-1404246356).

mreid-tt commented 2 weeks ago

@th0ma7, any thoughts on this older bug report?

th0ma7 commented 2 weeks ago

I'm no expert in this, and would require in depth testing to confirm and validate potential impacts on other armv7 archs part of the same generic arch packaging.

hgy59 commented 2 weeks ago

If we have packages that rely on the vfpv3-d16 flag, we need to consider the following:

So far we build generic armv7 packages with the armada38x Toolchain This includes the following archs (and TC_EXTRA_CFLAGS):

DSM6.2.4:

th0ma7 commented 2 weeks ago

noting maybe related https://github.com/SynoCommunity/spksrc/issues/6176