Skip to content

Conversation

@dsalychev
Copy link

I've successfully built and run graphics/drm-66-kmod with those patches on my Honeycomb LX2 with Radeon RX 460. With these patches 6.6-lts could be a substitute for anyone who relied upon retired graphics/drm-510-kmod.

This is how KDE Plasma desktop looks like on my Honeycomb LX2:

screenshot_20260105_110956

I've successfully built and run graphics/drm-66-kmod with those
patches on my Honeycomb LX2 with Radeon RX 460. With these patches
6.6-lts could be a substitute for anyone who relied upon retired
graphics/drm-510-kmod.

.if ${MACHINE_ARCH} == "aarch64"

dcn_calcs.o: dcn_calcs.c
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we avoid these duplicate rules? This is to remove -mgeneral-regs-only from all of these?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess so. I decided to act safely and removed -mgeneral-regs-only from those file clang complained about + dcn302_fpu.c as a special case explained above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean just arrange to have CFLAGS set appropriately rather than repeating the rules. I suspect that all of these correspond to the ${FPUFLAGS} additions for x86 above, like

CFLAGS.dcn_calcs.c= ${FPUFLAGS} -mstack-alignment=4

E.g. is there -mno-general-regs-only that we could set in ${FPUFLAGS} on arm64 to override -mgeneral-regs-only? Or something along those lines.

@dsalychev
Copy link
Author

Btw, as @bzfbd pointed out in a private discussion, Honeycomb LX2 has Cortex-A72 which are cache coherent which simplifies testing. But I don't have any other ARM64 with PCIe for a discrete GPU to test at the moment.

CFLAGS.rc_calc_dpi.c= ${FPUFLAGS} -mstack-alignment=4
CFLAGS.rc_calc_fpu.c= ${FPUFLAGS} -mstack-alignment=4

.if ${MACHINE_ARCH} == "aarch64"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost all of those files below use "double" as a type, i.e. clang blames ABI:

requires 'double' type support, but ABI 'aapcs' does not support it

but it's probably misleading diagnostics: llvm/llvm-project#90001

dcn301_fpu.o: dcn301_fpu.c
${CC} ${STATIC_CFLAGS} ${CFLAGS:N-mgeneral-regs-only} -c ${.IMPSRC} \
-o ${.TARGET}
dcn302_fpu.o: dcn302_fpu.c
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiling this one with -mgeneral-regs-only causes clang to produce machine code which requires __floatundidf to convert integer to double if I understand correctly, i.e.

kldload amdgpu

complains early about the undefined symbol.

#if defined(CONFIG_X86)
return boot_cpu_has(X86_FEATURE_HYPERVISOR);
#elif defined(CONFIG_ARM64)
return !is_kernel_in_hyp_mode();
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is_kernel_in_hyp_mode isn't available in the LinuxKPI. I didn't know how to substitute it properly and removed for now. Any suggestions are welcome.

#include <xen/xen.h>

/* XXX-DSL: For FreeBSD and LinuxKPI only! */
#if defined(CONFIG_ARM64)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be even more strict than "CONFIG_ARM64", I guess. I'm not sure.


.if ${MACHINE_ARCH} == "aarch64"

dcn_calcs.o: dcn_calcs.c
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess so. I decided to act safely and removed -mgeneral-regs-only from those file clang complained about + dcn302_fpu.c as a special case explained above.

@evadot
Copy link
Contributor

evadot commented Jan 6, 2026

Most (all ?) those are in the master branch. I started to fix stuff for arm64 a few weeks ago and if we want to have arm64 support again we should start by fixing the master branch.

@dsalychev
Copy link
Author

Most (all ?) those are in the master branch. I started to fix stuff for arm64 a few weeks ago and if we want to have arm64 support again we should start by fixing the master branch.

I've tried to apply the same patches on drm-latest-kmod, but kldload amgpu hangs very early. It didn't cause panic though. bz@ suggested some help, but next week most likely. I'd open a separate pull request against master for tests.

@evadot
Copy link
Contributor

evadot commented Jan 7, 2026

Most (all ?) those are in the master branch. I started to fix stuff for arm64 a few weeks ago and if we want to have arm64 support again we should start by fixing the master branch.

I've tried to apply the same patches on drm-latest-kmod, but kldload amgpu hangs very early. It didn't cause panic though. bz@ suggested some help, but next week most likely. I'd open a separate pull request against master for tests.

Yes it behave the same on me, I couldn't debug more as my honeycomb decided to died on me (still need to have a look at what's happening). But at least the patches should be cherry-picked from the main branch to 6.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants