Skip to content

AArch64 support #550

@grigorig

Description

@grigorig

Is there a chance of AArch64 builds of the userspace and kernel? What's missing to get this to work?

Activity

clivem

clivem commented on Mar 1, 2016

@clivem

kernel support!

popcornmix

popcornmix commented on Mar 1, 2016

@popcornmix
Contributor

This isn't going to happen from us any time soon. A 64-bit kernel is not trivial (and could be produced by community).

deborah-c

deborah-c commented on Mar 1, 2016

@deborah-c

Could it be produced by community? I think it might well need changes to the VC firmware to correspond, as interface structures would potentially change shape

popcornmix

popcornmix commented on Mar 1, 2016

@popcornmix
Contributor

The kernel could be. Depends on the implementation if the interface to VC needs to change. Forcing 32-bit pointers in interface to VC would be a sensible solution that wouldn't need a VC side change.

pelwell

pelwell commented on Mar 1, 2016

@pelwell
Contributor

MMAL is an awkward case, since it passes kernel pointers to the client and expects them to be echoed back - the space is 32-bits, so some form of compression or lookup table would be required.

6by9

6by9 commented on Mar 1, 2016

@6by9

MMAL is an awkward case, since it passes kernel pointers to the client and expects them to be echoed back - the space is 32-bits, so some form of compression or lookup table would be required.

Really? That doesn't sound right as kernel pointers have no meaning outside the kernel.
I'm happy to take a look if you'll email me details of the bit of concern.

6by9

6by9 commented on Mar 1, 2016

@6by9

Fair cop - not nice. V4l2 driver is just copying the way mmal did it.

How brave are we feeling? We could pull in the rpmsg mmal service instead, however that loses the bulk transfer facility so may need a slight change to the client code.

edit Hang on, that is the V4L2 driver only, so all kernel side. It's expecting VC to echo back a kernel pointer, not userspace.
I do have some changes planned for V4L2 which may help here (GSH and DC are aware). I'll check in a moment, but does the MMAL interface to userland have this same nastiness?

6by9

6by9 commented on Mar 1, 2016

@6by9

:-( Userland also expects VC to preserve a kernel pointer https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc/mmal_vc_msgs.h#L360
That is just VC and kernel side, so could be updated fairly easily, but would be an ABI change between firmware and kernel (or we need the firmware to try and handle multiple different versions of structure).
There's a couple of other pointers in structures passed to VC which would need attention too (eg https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc/mmal_vc_msgs.h#L421)

Are the other services OK?
IL had some niggles with having to set OMX_SKIP64BIT due to structure padding mismatches, but how does ILCS shape up more generally? Something will still need to reduce kernel 64bit pointers to 32 bit physicals for VC.
VCSM? Mailbox services?

My memory is failing me - did we ever get a 64bit kernel running? All userspaces were certainly 32bit.

ghost

ghost commented on Mar 1, 2016

@ghost

Speaking from a position of zero knowledge - how much of the Debian arm64 kernel source can be used before you run into problems?

deborah-c

deborah-c commented on Mar 2, 2016

@deborah-c

At Broadcom, the intention was 64 bit user land over 32 bit kernel, as a long term thing.

TheSin-

TheSin- commented on Mar 2, 2016

@TheSin-

why not 64bit across? Debian has a 64bit kernel and dist for arm. I know the Pi specific stuff would still need to be done, but why were they planning 32bit kernel? This is a curiosity question.

grigorig

grigorig commented on Mar 2, 2016

@grigorig
Author

32 bit kernel w/ 64 bit userland? I wasn't aware that this is a possible combination. Seems like a strange idea.

6by9

6by9 commented on Mar 2, 2016

@6by9

At Broadcom, the intention was 64 bit user land over 32 bit kernel, as a long term thing.

I'd remembered other way up - 64 bit kernel, 32 bit userland (as that was the current state of Android). I couldn't remember if that work had actually happened - did we actually have A53s in a chip that was brought up?

59 remaining items

domenkozar

domenkozar commented on Dec 30, 2018

@domenkozar

What's the state of this in 2019? I was trying to get kodi to work with raspberrypi firmware for hw accelerated video decoding on aarch64 and hit this issue.

pelwell

pelwell commented on Dec 30, 2018

@pelwell
Contributor

Hit what issue, precisely? This is a really old thread, and I doubt all the people on it are interested in your case - try opening a new issue if something isn't working as you would expect it to.

domenkozar

domenkozar commented on Dec 30, 2018

@domenkozar

Hardware video acceleration on Kodi using 64bit OS.

6by9

6by9 commented on Dec 31, 2018

@6by9

Hardware video acceleration on Kodi using 64bit OS.

Should now be possible on the 4.19 branch using the V4L2 M2M interface (supported by FFmpeg and hence Kodi). The LibreELEC guys were working on patches for FFMpeg to export dmabufs from V4L2 so that they could import into DRM, but that seems to have dropped down their projects list.

There may be one fixup that I need to push as mapping a kernel pointer into an IDR to pass as a 32 bit value to VC. I'll confirm when I'm back in the office.

domenkozar

domenkozar commented on Dec 31, 2018

@domenkozar

@6by9 that would be appreciated - especially how exactly should Kodi be compiled to work with ffmpeg and rbpi kernel.

sakaki-

sakaki- commented on Jan 19, 2019

@sakaki-

Hardware video acceleration on Kodi using 64bit OS.

Should now be possible on the 4.19 branch using the V4L2 M2M interface (supported by FFmpeg and hence Kodi). The LibreELEC guys were working on patches for FFMpeg to export dmabufs from V4L2 so that they could import into DRM, but that seems to have dropped down their projects list.

There may be one fixup that I need to push as mapping a kernel pointer into an IDR to pass as a 32 bit value to VC. I'll confirm when I'm back in the office.

@6by9 wow, that is really exciting news: once you confirm a valid kernel candidate (current tip rpi-4.19.y?), I will try to build a version of gentoo-on-rpi3-64bit with this acceleration enabled.

agsha

agsha commented on Sep 29, 2019

@agsha

Missing a 64 bit userland + kernel. I'm unable to use more than 4GB ram with swap enabled due to 32 bit kernel virtual memory

pelwell

pelwell commented on Sep 30, 2019

@pelwell
Contributor

Recent kernel releases include a trial 64-bit build. It hasn't made its way into the Raspbian kernel package yet, but you can install using sudo rpi-update. You will need to add arm_64bit=1 to config.txt because the firmware prefers the 32-bit build.

A 64-bit userland is not currently planned.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @domenkozar@swarren@niklas88@cleverca22@Ferroin

        Issue actions

          AArch64 support · Issue #550 · raspberrypi/firmware