Page MenuHomeFreeBSD

Backport armv7 architecture support to stable/11
AbandonedPublic

Authored by gonzo on Apr 15 2018, 2:39 AM.
Tags
None
Referenced Files
F105914124: D15071.diff
Sun, Dec 22, 2:02 PM
Unknown Object (File)
Thu, Dec 12, 4:49 AM
Unknown Object (File)
Sat, Nov 30, 11:45 AM
Unknown Object (File)
Sep 26 2024, 10:20 PM
Unknown Object (File)
Sep 8 2024, 11:30 PM
Unknown Object (File)
Sep 8 2024, 11:37 AM
Unknown Object (File)
Aug 26 2024, 8:24 PM
Unknown Object (File)
Aug 26 2024, 12:07 PM

Details

Reviewers
imp
linimon
manu
Summary

This backport includes revisions 322453, 324339, 324340, 324341, 324363
plus some manual fixes for armv7eb cehcks in Makefiles in gnu.
I booted it on RPi2, boots fine:

root@rpi2-11:~ # uname -a
FreeBSD rpi2-11 11.1-STABLE FreeBSD 11.1-STABLE #0 r332507M: Sat Apr 14 16:14:06 PDT 2018 gonzo@station.bluezbox.com:/src/FreeBSD/obj/arm.armv7/src/FreeBSD/11/sys/RPI2 arm

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 16140
Build 16093: arc lint + arc unit

Event Timeline

This looks sane to me. But I've not done end-to-end tests to prove it doesn't cause more harm.
Make sure releases still build.
And ports aren't screwed.

After email discussion, I think we now agree that it is incorrect to switch the kernels for 11 to armv7 by default. So, most of the changes in head/sys/arm/ are incorrect. (The addition of head/sys/arm/std.armv7 must stay, of course.)

I am working on a patch that does all the above.

After email discussion, I think we now agree that it is incorrect to switch the kernels for 11 to armv7 by default. So, most of the changes in head/sys/arm/ are incorrect. (The addition of head/sys/arm/std.armv7 must stay, of course.)

I am working on a patch that does all the above.

It's not clear to me that it's the case that switching the kernels is incorrect.

People are confusing too many issues on this, and the email discussions aren't complete.

It's not clear to me that it's the case that switching the kernels is incorrect.

Unless we explicitly tell all users to use the pkg.conf remap, or the lonesome.com armv7 packages, stable/11 users will regress.

It's not clear to me that it's the case that switching the kernels is incorrect.

Unless we explicitly tell all users to use the pkg.conf remap, or the lonesome.com armv7 packages, stable/11 users will regress.

Since arm is tier 2, I'm not sure what the problem here is. We make no guarantees for tier 2 platforms. Users will still be ABLE to boot a kernel where they won't see a regression, which is another path forward as well. It's a release notes item.

Since arm is tier 2, I'm not sure what the problem here is. We make no guarantees for tier 2 platforms.

Going from "there have been supported FreeBSD packages for a year or so" to "there are no longer any packages" is POLA out the ass.

Since arm is tier 2, I'm not sure what the problem here is. We make no guarantees for tier 2 platforms.

Going from "there have been supported FreeBSD packages for a year or so" to "there are no longer any packages" is POLA out the ass.

And there's at least three remedies that can be documented in the release notes. Oh, wait, 4 ways: we can put armv6 alias in the pkg.conf file by default and there'd be no issue.

We can put armv6 alias in the pkg.conf file by default and there'd be no issue.

We're gated on that buy-in, before I can support the patch, that I created myself.

Sigh.

I have created another review with my latest suggestions (apparently I can't grok phab) as D15129.

So why don't we have armv7 packages yet?

This revision is now accepted and ready to land.Oct 9 2020, 6:25 PM