BPi Android 4.2 Build Guide

72 19313
ChrisP  
build went further, but:

Copy: out/target/product/sugar-bpi/system/vendor/modules/warrior.ko
Copy: out/target/product/sugar-bpi/system/vendor/modules/sun7i-keypad.ko
Copy: out/target/product/sugar-bpi/system/vendor/modules/tsc40.ko
Copy: out/target/product/sugar-bpi/system/vendor/modules/analog.ko
make: *** No rule to make target `prebuilts/qemu-kernel/arm/LINUX_KERNEL_COPYING', needed by `out/target/product/sugar-bpi/obj/NOTICE_FILES/src/kernel.txt'.  Stop.
make: *** Waiting for unfinished jobs....

mattrix  
Edited by mattrix at Tue Nov 25, 2014 17:32

Ok.
It does need qemu-kernel.
Will add back in

NOW ADDED

Please try git pull and build

I read on a few forums that the multicores on that make for the android image can cause headaches.
So, decided to remove.

Also found the problem with my compiling was lack of memory on my cloud PC.
Have enabled SWAP now so hopefully I can make a good build.

ChrisP  
Edited by ChrisP at Wed Nov 26, 2014 00:34

ok, trying, but I think it will be over for me this evening, time for some sleep, will continue tests later

apparently some issue with the cpu identification:

./build.sh: line 8: /proc/cpuinfo: Permission denied
0
./build.sh: line 10: [: -le: unary operator expected
./build.sh: line 13: /: Is a directory

This time another error, but less obvious. I put the end of the logs in the attached file:

error.zip (5.01 KB, Downloads: 6)

mattrix  
ChrisP replied at Tue Nov 25, 2014 17:22
ok, trying, but I think it will be over for me this evening, time for some sleep, will continue test ...

Please see my last comment about this

ChrisP  
ok, good luck, will see later ;)

mattrix  
Edited by mattrix at Tue Nov 25, 2014 18:38

Yup. Your getting the random "killed" like I was.
This is due to lack of memory.

If using a VM - give it some more memory.
If not a VM, enlarge / enable swap file.

Added back in the multicore code you submitted
Makes it a lot quicker.

mattrix  
OK!
Should be good to go now

So, all you need to do on a fresh 14.04 system is
  1. apt-get install git
  2. git clone https://github.com/matthuisman/android ANDROID
  3. cd ANDROID/scripts
  4. ./install_14.04.sh
  5. ./build.sh
Copy the Code
Done.
You will end up with an bpi_android.img in the ANDROID directory.

dlanor  
ChrisP replied at Tue Nov 25, 2014 02:07
false is to disable haptic response which cannot be used on this device (pure cosmetic code change)
...

@ChrisP: The text in the frame below was the complete text of one of your posts, and it looks very interesting.
Unfortunately I don't understand its context, since you never explained what file the info refers to.
I assume this stuff is part of some configuration script file somewhere, but guesswork won't resolve it for me.

Please clarify which precise file this stuff belongs in:

  1. <bool name="def_haptic_feedback">false</bool> is to disable haptic response which cannot be used on this device (pure cosmetic code change)
  2. <bool name="def_install_non_market_apps">true</bool> is to make additionnal apps store accepted by default.
  3. <bool name="def_user_setup_complete">true</bool> is to try to get rid of the inital "wizard" telling you what to do. Not yet so effective :/
Copy the Code
Best regards: dlanor

mattrix  
dlanor replied at Wed Nov 26, 2014 01:49
@ChrisP: The text in the frame below was the complete text of one of your posts, and it looks very ...

"android/device/softwinner/sugar-bpi/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml"

is the location for that setting

https://github.com/matthuisman/a ... values/defaults.xml

dlanor  
Edited by dlanor at Wed Nov 26, 2014 02:52
mattrix replied at Tue Nov 25, 2014 14:20 We need the complete source in a GIT repo.
The benefits of having it in a repo is huge and shouldn't need explaining.
Transferring 3GB files around the internet is not good for anyone.
I agree, of course. I never argued against your repo.
(Perhaps I phrased that post badly, as I was in a hurry at the time.)

Hosting just the changes as well is not ideal.
Not as the only repo. But it can be a useful way to present individual patches and deviations from the main repo.
It can be a good way to share things for testing and improvements which are not yet ready for adding to the main repo.

Regarding VMware VS VirtualBox:
VMware offers a choice of how many CPUs to emulate and how many virtual cores each virtual CPU should have.
And even with a total number of virtual cores set to just 1, the emulator software can still use more, though it only emulates 1.
But software in the guest OS intended for multi-core use will of course work better with more virtual cores being emulated.

VirtualBox also offers a choice of how many CPUs to emulate, though it's really a choice of cores, without emulating the ties between core and the CPU they belong to.
So I guess my  earlier phrasing was incorrect. It's not multi-core that VBox is lacking, but multi-CPU emulation.
Also, the GUI shows a red warning for any choice above 3, which I consider silly for a physical i7 CPU which has 4 physical cores and 8 threads.

As for Vagrant I don't use it. What does it offer beyond what the VBox GUI does ?

All-in-all I simply prefer using VMware. I guess it's a matter of personal taste.
I especially dislike how the VBox 'Guest Additions' modify the behavior of Ubuntu's Unity GUI.

If you look in the build script for the Kernel, it's actually using -J* anyway
Good. Then we don't need to change build instructions to handle it.

Edit:
But in a later post you seem to be saying that this multi-core use had to be disabled for stability.
Was this really the case ? Or was the instability rather due to some other problem (like too little RAM) ?

Best regards: dlanor

You have to log in before you can reply Login | Sign Up

Points Rules