You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
Activity
clivem commentedon Mar 1, 2016
kernel support!
popcornmix commentedon Mar 1, 2016
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 commentedon Mar 1, 2016
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 commentedon Mar 1, 2016
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 commentedon Mar 1, 2016
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 commentedon Mar 1, 2016
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.
pelwell commentedon Mar 1, 2016
Take a look here:
https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/media/platform/bcm2835/mmal-msg.h#L259
here:
https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/media/platform/bcm2835/mmal-vchiq.c#L424
and here:
https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/media/platform/bcm2835/mmal-vchiq.c#L510
6by9 commentedon Mar 1, 2016
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 commentedon Mar 1, 2016
:-( 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 commentedon Mar 1, 2016
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 commentedon Mar 2, 2016
At Broadcom, the intention was 64 bit user land over 32 bit kernel, as a long term thing.
TheSin- commentedon Mar 2, 2016
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 commentedon Mar 2, 2016
32 bit kernel w/ 64 bit userland? I wasn't aware that this is a possible combination. Seems like a strange idea.
6by9 commentedon Mar 2, 2016
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 commentedon Dec 30, 2018
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 commentedon Dec 30, 2018
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 commentedon Dec 30, 2018
Hardware video acceleration on Kodi using 64bit OS.
6by9 commentedon Dec 31, 2018
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 commentedon Dec 31, 2018
@6by9 that would be appreciated - especially how exactly should Kodi be compiled to work with ffmpeg and rbpi kernel.
sakaki- commentedon Jan 19, 2019
@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 commentedon Sep 29, 2019
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 commentedon Sep 30, 2019
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 addarm_64bit=1
to config.txt because the firmware prefers the 32-bit build.A 64-bit userland is not currently planned.