I plan on moving gralloc for Mali into it's own repo an wondering whereabouts in the source tree it should be placed by the manifest? Possibilities are
/hardware/arm/mali/ /external/mali/ /mali/
Within whatever directory is chosen I plan on having source for all the versions of mali so, e.g.
/hardware/arm/mali/r5p0-06rel0/gralloc /hardware/arm/mali/r5p1-00rel0/gralloc /hardware/arm/mali/r5p1-06rel1/gralloc
With the aim being that the correct one gets chosen to match whatever driver version is in the kernel. I also plan similar for vendor tarball contents, so hopefully we get builds where the three pieces are guaranteed to have matching version (kernel module/gralloc/binary blob)
On 1 June 2015 at 19:59, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I plan on moving gralloc for Mali into it's own repo an wondering whereabouts in the source tree it should be placed by the manifest? Possibilities are
/hardware/arm/mali/ /external/mali/ /mali/
Within whatever directory is chosen I plan on having source for all the versions of mali so, e.g.
/hardware/arm/mali/r5p0-06rel0/gralloc /hardware/arm/mali/r5p1-00rel0/gralloc /hardware/arm/mali/r5p1-06rel1/gralloc
I would suggest it to be /vendor/arm/mali/
With the aim being that the correct one gets chosen to match whatever driver version is in the kernel. I also plan similar for vendor tarball contents, so hopefully we get builds where the three pieces are guaranteed to have matching version (kernel module/gralloc/binary blob)
Are you planning to checkin the binaries into a git repository ?
-- Tixy
linaro-android mailing list linaro-android@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-android
On Mon, 2015-06-01 at 20:15 +0530, Vishal Bhoj wrote:
On 1 June 2015 at 19:59, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I plan on moving gralloc for Mali into it's own repo an wondering whereabouts in the source tree it should be placed by the manifest? Possibilities are
/hardware/arm/mali/ /external/mali/ /mali/
Within whatever directory is chosen I plan on having source for all the versions of mali so, e.g.
/hardware/arm/mali/r5p0-06rel0/gralloc /hardware/arm/mali/r5p1-00rel0/gralloc /hardware/arm/mali/r5p1-06rel1/gralloc
I would suggest it to be /vendor/arm/mali/
Wouldn't that clash somewhat with the vendor tarball that put the binary blobs in the same path? I.e. extracting the blobs would make the source directory for Mali dirty as far as git was concerned. Though it does have an appeal putting the sources and blobs in the same location.
With the aim being that the correct one gets chosen to match whatever driver version is in the kernel. I also plan similar for vendor tarball contents, so hopefully we get builds where the three pieces are guaranteed to have matching version (kernel module/gralloc/binary blob)
Are you planning to checkin the binaries into a git repository ?
Unfortunately I can't as they require a click through licence. So blobs will have to be distributed using the current method. I was just planning on putting the blobs in the tarball using a a different path.
Basically, my hope was that the kernel code (where the Mali kernel module source is) will have a simple file (MALI_SOFTWARE_VERSION) containing
MALI_SOFTWARE_VERSION=mali-t62x_r5p0-06rel
so when building Android we can
include kernel/linaro/armv8/drivers/gpu/arm/MALI_SOFTWARE_VERSION
Then we can use that to select the gralloc to build (don't know exactly how and where to do this bit)...
include hardware/arm/mali/$(MALI_SOFTWARE_VERSION)/gralloc/makefile
Then in device/linaro/juno/device.mk copy the correct blobs with...
# Find highest version of mali binaries in vendor/arm that is prefixed $(MALI_SOFTWARE_VERSION) MALI_BINARIES := $(patsubst $(TOP)/%,%,$(lastword $(sort $(wildcard $(TOP)/vendor/arm/mali/$(MALI_SOFTWARE_VERSION))))) ifneq ($(MALI_BINARIES),) PRODUCT_COPY_FILES += $(call add-to-product-copy-files-if-exists,\ $(MALI_BINARIES)/lib64/egl/libGLES_mali.so:system/lib64/libGLES_mali.so \ $(MALI_BINARIES)/lib64/egl/libGLES_mali.so:system/lib64/egl/libGLES_mali.so \ $(MALI_BINARIES)/lib/egl/libGLES_mali.so:system/lib/libGLES_mali.so \ $(MALI_BINARIES)/lib/egl/libGLES_mali.so:system/lib/egl/libGLES_mali.so)
And so we end up with matching versions of everything, or missing versions, rather than a potential mixture of incompatible code.
What's prompted this is that ARM want to start keeping things up-to-date with the latest version of things, e.g. I have a old new one for 15.06 and another new new one probably the month after. So I wanted to implement something to make rollout of updates as seamless as possible.
On Mon, 2015-06-01 at 16:24 +0100, Jon Medhurst (Tixy) wrote:
On Mon, 2015-06-01 at 20:15 +0530, Vishal Bhoj wrote:
[...]
I would suggest it to be /vendor/arm/mali/
Wouldn't that clash somewhat with the vendor tarball that put the binary blobs in the same path? I.e. extracting the blobs would make the source directory for Mali dirty as far as git was concerned.
Of course, can use .gitignore for that.
Though it does have an appeal putting the sources and blobs in the same location.
So think that's what I'll do. I'll prototype something then get further opinions and review.
linaro-android@lists.linaro.org