On Monday, March 30, 2015 12:00 AM, Vishal Bhoj wrote:
On 29 March 2015 at 21:07, Vishal Bhoj <email@example.com mailto:firstname.lastname@example.org> wrote:
I have compiled the Mali kernel module for Android and tried to boot Android based on Scott's proposed change.I am able to load the mali kernel module but I am getting an error while surfaceflinger tries load the GLES libs and use the same. The logcat and dmesg output is here: https://pastebin.linaro.org/view/93ad6748
Did some changes to pick the right gralloc lib and the ion library. It still fails. Here is the logcat:
@xuzixin I have attached these two log file. Please take a look at them.
Gralloc tries to request fb with triplebuffering configuration but current FB is configured for single buffer (looks like): <3>[ 51.649450] [drm:hisi_drm_fb_helper_check_var] *ERROR* fb userspace request width/height/bpp is greater than current fb request 1280x720-32 (virtual 1280x2160) > 1280x1440-32 <7>[ 81.907649] calling init_module+0x0/0x6c [mali] @ 1755 <6>[ 81.908408] ion: heap info : id 10 name fb phy 0x37300000 size 26214400 <4>[ 81.917596] Mali: GPU version: CF070000 <4>[ 81.930435] Mali: Mali device driver loaded <7>[ 81.934911] initcall init_module+0x0/0x6c [mali] returned 0 after 26431 usecs <14>[ 101.000830] healthd: battery none chg= <3>[ 111.007480] [drm:hisi_drm_fb_helper_check_var] *ERROR* fb userspace request width/height/bpp is greater than current fb request 1280x720-32 (virtual 1280x2160) > 1280x1440-32
Regards, Vishal On 27 March 2015 at 19:02, Guillaume Tucker <email@example.com <mailto:firstname.lastname@example.org>> wrote: On 26/03/15 17:48, Jorge Ramirez-Ortiz wrote: On 03/26/2015 11:15 AM, Scott Bambrough wrote: I've been going around with Jorge for a couple of days with this. He doesn't see the error but I do using make 4.0. I have spoken with Vishal and he sees this error with make 3.81, and tells me Fathi sees this error in local builds. Works for me with GNU Make 3.81 on Ubuntu 12.04. I didn't remove anything from Kbuild in the patch I sent you as I didn't hit this issue, but the bit of logic involved only tends to make sense when the driver is built out-of-tree. So in this context I think it can be simplified as Scott suggested (i.e. by removing the license test) as we know it's all GPL. on my side it builds fine (I havent been able to reproduce the error using the following) [jramirez@calypso-2 ~]$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" [jramirez@calypso-2 ~]$ make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu and [jramirez@calypso ~]$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.10 DISTRIB_CODENAME=utopic DISTRIB_DESCRIPTION="Ubuntu 14.10" [jramirez@calypso ~]$ make -v GNU Make 4.0 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782