ARM64 should be now work complete

[Electron752]

So it appears that all the needed bits for ARM64 have been merged now in upstream Linux. This was my primary goal here and it now appears to be approaching or has reached work complete.

Does anybody have any suggestion on where this could all go next?

I do know that Mathematica still doesn't work on Raspbian due to various issues.

[popcornmix]

We have a rpi-4.11.y tree that is largely working. How much 64-bit support is present in this tree?
We're generally happy to accept backports from upstream as long as someone finds them useful and they don't cause problems.

Mathematica is specifically licensed for raspberry pi, so I wouldn't be surprised if there are some sanity checks on the processor type which arm64 may unintentionally break.

[Electron752]

rpi-4.11.y doesn't quite have enough to run the hello_pi examples or minecraft_pi, etc because It's lacking the vchiq compat stuff. That was all added as a single change it upstream, which I believe is still in linux-next. I'm not sure you can pull a commit from linux-next though.

I do know what it takes it get Mathematica to load from arm64. Upstream is missing a few small changes to report the correct processor type when running in 32 bit mode. I actually have them, but I doubt they would even be considered in upstream. Would you consider them for downstream only?

Oh, and the camera changes for 64 bit where added as a series of commits that I think is still in linux-next. But I think apps such as Raspicam should still work without it.

Other then that, I think arm64 should be 100% complete.

[popcornmix]

I don't have any objections to any of those changes.

[ED6E0F17]

What is the status of compatibility layers for:

CONFIG_BCM_VC_CMA=y
CONFIG_BCM_VC_SM=y

These are not needed for 64-bit userspace, where there is no intention of porting Raspbian or Userland, but they would be useful for running 32-bit Raspbian with a 64-bit kernel.

[Electron752]

At the moment those don't work. I was planning to just ignore BCM_VC_CMA because my understanding is that it never worked well.

The other driver could probably get fixed rather easily.

[popcornmix]

Agreed - BCM_VC_CMA is something unsupported by us and is no longer enabled in rpi-4.11.y tree as it is not recommended.

CONFIG_BCM_VC_SM is useful.

[6by9]

CONFIG_BCM_VC_SM is useful.

Soon to be required once I get to dmabufs for V4L2 and MMAL (probably a week or so away). That is the service I intend to use to support import a dmabuf and convert into a mem_handle for use by the GPU, or export a gpu_mem allocation as a dmabuf.
For the V4L2 case of wrapping a contiguous buffer I could do it via a new MMAL call instead, but not for a more general import case, nor exporting.

These are not needed for 64-bit userspace, where there is no intention of porting Raspbian or Userland, but they would be useful for running 32-bit Raspbian with a 64-bit kernel.

I'm not sure I follow the logic there in the case of VC_SM. It has no relevance whether things are 32 or 64 bit, but total relevance as to how GPU memory is handled. If you want to map gpu memory directly into the ARM world, then VC_SM is the tool to do that.

[Electron752]

I'm still a bit confused about what is going one here and what not. Was this all just to prove me wrong or something? If this is really something new from a certain west coast US company, I never had any beef with them. I just never considered their stuff before because they always required big noisy fans and what not.

Is my RPI 3 aarch64 kernel running on bare metal, or is it in just some kind of weird user mode simulation/sandbox?

I mean I hope I helped some with this whole thing and such. I can probably get VC_SM working rather easily, but I'm not really sure if help is wanted or even needed at this point.

[JamesH65]

Not quite sure what you are getting at, but I can assure you nothing said here is to prove you wrong. What 6x9 has stated is how parts of the v4l2 and MMAL subsystems are going to be modified in the very near future by the RPF/T to make them better (more speed, less memory requirement, less SDRAM bandwidth). This means we need shared memory handling between Linux (32 or 64bit) and the GPU. This shared memory means less buffer copying, and this will be enabled by the switch quoted. No conspiracy here, just a development path.

…

On 27 March 2017 at 17:40, Electron752 ***@***.***> wrote: I'm still a bit confused about what is going one here and what not. Was this all just to prove me wrong or something? If this is really something new from a certain west coast US company, I never had any beef with them. I just never considered their stuff before because they always required big noisy fans and what not. Is my RPI 3 aarch64 kernel running on bare metal, or is it in just some kind of weird user mode simulation/sandbox? I mean I hope I helped some with this whole thing and such. I can probably get VC_SM working rather easily, but I'm not really sure if help is wanted or even needed at this point. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1915-23issuecomment-2D289511037&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=qZ9wEcd2mEQhkNviOHIWhdxrC-N89q5purlwm0MtgHM&s=zSwfLyZLuh17xE4G8aNGBjBGsdIbAqFM5azcI2Uq6t0&e=>, or mute the thread <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHSyuR736q6MDBQpiPii-2D4vR4Jquoks5rp-2DaWgaJpZM4MoLzb&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=qZ9wEcd2mEQhkNviOHIWhdxrC-N89q5purlwm0MtgHM&s=PSSNm3LEPHKX3dVSUtRAE1-u-X-qPhtyz4vlrhB0Xfo&e=> .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[Electron752]

I know what I need to do, but it's going to take awhile for me to make the changes correctly. I'm having a bit of difficulty getting things to work, but I'll keep trying .

[ED6E0F17]

If you want to map gpu memory directly into the ARM world, then VC_SM is the tool to do that.

but if you want to map ARM memory onto the GPU you would use cma. What benefits do you get from using VC_SM instead of an interface that is already used upstream ?

[6by9]

Sorry, I need to be more careful about using GPU vs VPU.

CMA will allocate a contiguous block of memory that the kernel knows how to handle, but is foreign to the VPU. In that form it is therefore totally useless for achieving a zero copy solution for any camera (including via V4L2) or video codecs use case.
Something needs to be used to take the details of a contiguous block of memory and pass it to the VPU in a suitable format. My intention is to use VC_SM as that already exists to handle VPU MEM_HANDLES, convert them to/from kernel representations, and clean up on the app terminating abnormally.
Mailboxes don't have any notion of "connection", so we can't handle the cleanup with that API, and it seems daft creating a whole new VCHI service when we already have a service for sharing memory.

Please correct me if I'm wrong, but I also see a missing chunk in upstream - userspace is unable to allocate from CMA, so userspace can't pass larger blocks of memory without having a specific driver to handle it.
Android's Ion is being cleaned up to move out of staging, but that's based around heaps rather than just CMA. I don't believe there are any other APIs around attempting to offer similar allocation services of contiguous blocks of memory. I was struggling to find anything much that handled CMA and exporting as dmabufs so that things really can be passed around.

More complete details of my current plans on #1806 and #1807.

There is further discussion to be had over how things migrate from having gpu_mem needing to be 64 or 128M into using CMA and vc4-kms-v3d. Even with the above VC_SM changes that is only covers the data exchanged with the ARM. Both camera and codecs need internal working buffers to be allocated from somewhere. Potentially a reverse memory request from the VPU to kernel to allocate/free a block. How would that integrate into dmabuf, and does that make sense?

[ED6E0F17]

Thank you for explaining, the links back to previous issues were very helpful. I see that you have already considered:

 VCSM could be rejigged to use CMA by default as the allocator and map it into VC, as a new implementation of vc_sm_alloc().

So I accept your conclusion that CMA alone is not good enough.

[Electron752]

There once was a TV show called, "Twin Peaks". This whole RPI thing is sort of becoming like that. Everything starts out simple, but as things go the more complex and weird it gets.

So, I'm still trying to understand the boot process here and exactly what the physical limitations are that people are trying to work around.

Here is what I understand so far:
The VPU has a bootrom and bootram and that's the initial point of execution for the VPU. This bootrom has enough stuff to get bootcode.bin somehow loaded from the SD card(or USB or Network) into the cache. This activates the external RAM(1 GB in the RPI 3) which is on a different chip. The VPU running from the cache, loads the various .elf and .dat files into the external RAM and jumps into that. These .elf files start up the ARMs which load the kernel or uboot or whatever.

OK, now is what I think is a huge part of the puzzle here. The bootrom and bootram, appears to need almost as much capability as bootcode.bin(it needs to parse the filesystem, use USB, load files, etc). Yet it's only 32KB instead of the normal 64KB or bootcode.bin. So how can it be half the size?

I really only see two really possibilities here:

1. Some other information is being loaded somewhere. Another Flash area or external chip.
2. To really mess things up, this whole thing is itself running in a VM or simulator that itself has the facilities to get things going. I do see a HOST interface register in the register definitions that are floating around.