the branch that i’m using is 3.4.2
Hi @Zacchaeus_Liang,
Does your HDMI issue solved??If no,Please try with the following set of patches
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889696
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889697
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889698
1 Like
@sreegink @Zacchaeus_Liang @liuyunli @quincysquarrel
Just want to clarify some things. The 3.4.2 build can boot to the Home screen, but the kernel for the build has issues displaying properly on some/certain/many(?) monitors, which can be resolved by the 3 kernel/hikey-linaro (889696-889698) patches mentioned above. The 3.8.3 build cannot boot to the Home screen. The root cause is unknown. If any one of you guys can figure it out that’d be great, but applying those 3 patches won’t help, because they should have already been applied. You can verify by checking the source code under kernel/linaro/hisilicon-4.14.
@vchong
Is 3.4.2 the latest version that is known to be able to boot to home screen ? What about 3.6.x ?
You all can try below if you want. It’s a temporary/wip/messy/unsupported build so use at your own risk.
- AOSP somewhere between 11 and 12
- OP-TEE 3.9
- Fully Clang built bootloader
- FBE enabled by default
- Kernel 4.14 (can possibly try building with 5.4 but haven’t tried and don’t know what will happen)
- Boot to home screen. Ignore the initial home screen error message about problem with the device and contacting the manufacturer. It happens with stock AOSP builds too so not sure what’s going on there.
- No adb over usb, but over tcp is ok
so i tried to flash the image and it didn’t work. I had to change my flashing script since i’m building remotely
essentially i’m copying over what’s in the device/linaro/hikey/installer/hikey960 and moving it onto my local machine
fastboot flash ptable ptable-aosp-32g.img
fastboot flash xloader hisi-sec_xloader.img
fastboot reboot-bootloaderfastboot flash fastboot l-loader.bin
fastboot flash fip fip.bin
#fastboot flash nvme hisi-nvme.img
fastboot flash nvme nvme_bs4096_js_raw.img
fastboot flash fw_lpm3 hisi-lpm3.img
fastboot flash trustfirmware hisi-bl31.bin
fastboot reboot-bootloaderfastboot flash ptable ptable-aosp-32g.img
fastboot flash xloader hisi-sec_xloader.img
fastboot flash fastboot l-loader.bin
fastboot flash fip fip.binfastboot flash boot boot.img
fastboot flash system system.img
fastboot flash vendor vendor.imgfastboot flash userdata userdata.img
my question is am i using the right files?
- You need to run the fastboot commands on the same machine that the hikey960 is plugged into via USB.
- The hikey960 needs to be in fastboot mode (see hardware documentation).
- Only the LAST FOUR of those lines listed are necessary or should be used regularly, since they are the only ones that actually change when you generate a build.
- The location for those files will be {AOSP ROOT}/out/target/platform/hikey960/ on the machine on which they are built.
1,2 i’m doing them
3. i’ll try doing that
4. yes and there’s a command to transfer to the other directory that i’m referring to
cp -a out/target/product/hikey/*.img device/linaro/hikey/installer/hikey/
EDIT: i flashed the last 4 lines and no lights turn on once it boots
Anything on your debug console or adb logcat?
no sign of life from the board
@Zacchaeus_Liang You’re using the right files but please remove all the fastboot reboot-bootloader commands. Those aren’t required anymore afaict. Also, the list of images to be flashed can be reduced to:
fastboot flash ptable ptable-aosp-32g.img
fastboot flash xloader hisi-sec_xloader.img
fastboot flash fastboot l-loader.bin
fastboot flash fip fip.bin
fastboot flash nvme nvme_bs4096_js_raw.img
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot flash userdata userdata.img
@doitright As mentioned previously in Disk encryption in android - #10 by vchong, the OP-TEE AOSP build scripts make changes to the bootloader sources, so users need to flash some of the other related partitions as well.
‘does not work at the moment’ is not a lot to go by. If you’re flashing from recovery mode (switches 1-2, 3-4 on, 5-6 off), you need to take the board out of that mode before you can boot into a normal working mode. Otherwise, try these confirmed working prebuilt images to see if the board is really bricked or not.
should i have it in fastboot mode? i set it back to normal mode after flashing i don’t think i can use fastboot in recovery mode.
Both normal or fastboot mode is ok. If using fastboot mode, you just need to press a key at the fastboot mode prompt in order to continue booting to the console.
The recovery mode is for when the bootloader itself is faulty, e.g. you can’t even boot into fastboot mode to flash images. In recovery mode, you run hikey_idt -c config, where config is a text file specifying the path to 3 images required for the recovery. If the command completes successfully, the board will load the fastboot prompt, where you can flash the proper bootloader images to recover the board and any other images as well if necessary. After that you just take the board out of recovery mode and boot into fastboot or normal mode like you always do. The flash-all.sh script operates under the assumption that the board is in recovery mode.
In fastboot mode, you can also flash bootloader and other images, but if you flash something faulty, then on reboot you might not be able to get back into fastboot mode again, which requires recovery mode to fix, as explained above.
Double check your dip switch settings to confirm which mode you’re in. I’ve in the past mistaken on for off and vice versa, and thought the board was fried as well. If you still see no activity at all in the console after powering up, then try the recovery process with the prebuilt images.
I can flash a different build of the source tree after trying the flash of the new branch. I know my fastboot is fine. i’m very aware of my dip switch configuration.
If fastboot is fine, then the board is probably still ok. Did you just mean that the images built from the new branch aren’t working? If so, can you please try the prebuilt images above and see if those work?
it does work! but my problem right now is there’s no option to set a password (how is it able to be encrypted?) which i need and also evertime i try to adb as root ( adb works for some reason) the device resets. how did you build it?
commands i use since i need to build android’s settings app.
lunch hikey960-userdebug .build/envsetup.sh make
that’s how I’m building it.
it does work!
What does work? The prebuilt images, or the images built from the new branch? If images built, then what was the issue with the board showing no signs of life?
there’s no option to set a password
You’re right. I only see the None and Swipe options. Not sure what’s going on here. If I try to set a password via the cli, it says that “The device does not support lock screen - ignoring the command”. Can’t Add an account either. This may be one of the drawbacks of working with the master branch. :s Were you able to set a password using images from the 3.4.2 build?
how is it able to be encrypted?
Sorry but I don’t know exactly how FBE works under the hood either. File-Based Encryption | Android Open Source Project seems to indicate that it doesn’t depend solely on the password anymore. I also seem to have a faint recollection of reading something about rebinding the encryption process to a password if recreated, but wasn’t able to find the article again. Afaik, vold generates a key through the keymaster hal for the encryption. This key is stored under /data/unencrypted/key/keymaster_key_blob. If you look under Settings > Security > Encryption & credentials, you can see that the device is Encrypted.
evertime i try to adb as root ( adb works for some reason) the device resets
One of my coworkers had this issue too with the mainline vanilla build, but only for the first time. It was fine after that. Can you maybe try adb over tcp and see if that makes a difference? Don’t feel very hopeful though.
that’s how I’m building it.
Build command is fine. What about your sync commands? You need to run the sync script in order to get the patches for OP-TEE.
it was working with the prebuilt images.
You’re right. I only see the None and Swipe options. Not sure what’s going on here. If I try to set a password via the cli, it says that “The device does not support lock screen - ignoring the command”. Can’t Add an account either. This may be one of the drawbacks of working with the master branch. :s Were you able to set a password using images from the 3.4.2 build?
there was a option to change the password but it does not save or show the lock screen with the password
i’m syncing with sync-master-hikey960.sh
