AOSP Automotive 9

Products Support HiKey 960
#1

Here is an early, but somewhat working device tree:

There is an selinux hack that im keeping in this “issue” (second message):

Use the known good manifest from Sept 11, with the above device and sepolicy hack. It should boot to a working UI, but there is a lot to do still.

2 Likes
HiKey960 linaro kernel - compile from source issue
#2

My initial observations on the obvious changes in automotive 9 are these:

  1. the nav bar has been re-styled. Its cleaner now with left-leaning icons.
  2. it now has a much more proper launcher, by default. No more need to hack in Launcher3.
  3. they have folded the “overview” (notifications application) into the launcher, but have included a separate icon for it on the nav bar.
#3

New kernel is now brought up to date for Automotive service.

Need to debug amfm radio, gps, and lcd backlight, then it should be all “working”, after which I need to fix the sepolicy to return to enforcing, and that should be the bulk of it.

#4

GPS is now fixed.
As is the broadcastradio HAL (but missing a couple of hacks needed to actually activate the sound path).

I’ll fix the backlight tomorrow, it will actually be quite easy, I think.

#5

Didn’t do the lights hal yet, but have sound almost working correctly now. The missing piece of sound is that it seems that they’ve increased the number of volume steps for HFP from 15 to 255. Fairly trivial change needed to the audio hal for that, and the lights hal still should be easy.

I’ve got updated patches in the “instructions” repo: Files · master_091118_car96 · HiKey960-Car / HiKey960-Car · GitLab

Updated device repo: Files · master_091118_car96 · HiKey960-Car / android_device_linaro_hikey · GitLab

Updated kernel: Files · android-hikey-linaro-4.9_092518 · HiKey960-Car / android_kernel_linaro_hikey_OLD · GitLab

Note that those patches in there have some DIRTY DIRTY DIRTY hacks, which I intend to eliminate… but first step is make it compile, second step is make it work, and third step is make it right. I’m nearly done the second step – just 2 outstanding issues.

#6

Lights and call volume are now working. Thats everything. Now its time to make it right.

#7

And the first step towards making it right: No longer need the dirty dirty dirty selinux hack.

And overall, there are just 2 extra patches needed, which are two parts of the same hack, which I will also be able to eliminate. I think I just need to make a few changes to the audio hal, and add the audiocontrol hal in order to use the native audio patch capability, rather than hacking in my own audio patch.

And of course, returning selinux to enforcing.

Its all pretty close now.

1 Like
#8

So now we can build without Launcher3 ? e.g.:

. build/envsetup.sh
lunch hikey960_car-userdebug
UBLOX_GPS_HAL=TRUE DMHD1000=TRUE HDMI_RES="1920x1080@60" m -j4
#9

Yes, launcher3 is now redundant.
I haven’t got the DMHD1000 HAL in there right now, so that parameter won’t help you.

#10

Ok, I don’t have this radio anyway. I have small FM tuner (based on Si4703) connected via I2C and I’m thinking if it’s possible to adapt your impl in /broadcastradio to my FM tuner…

So the 2 patches you mention are only Radio related?

0001-Car96-HACK-Send-media-volume-updates-to-AMFM-radio.patch
0001-Car96-HACK-Use-custom-audio-patch-for-car-radio.patch

#11

That’s not even close to an automotive radio and really won’t do a good job for automotive purposes. I wouldn’t waste time on it.

Get one of these; https://www.aliexpress.com/item/Radio-module-with-TEF6686-TDQ-230V-86-TDQ-230V-86-R-2PCS-Lot/32809641460.html

They’re dirt cheap automotive radios, and I’ve got a HAL in place that runs them. The downside to those radios is that the manufacturer (NXP) has decided to hoard the documentation. Fortunately, I was able to find working and well documented source code deep in the chinese side of the internet.

Shortly, I’m hoping to start working on a new radio module, using si4743. A proper automotive radio, with proper documentation.

#12

Kind of. They actually are used to open and close an audio route that connects the line level input for the radio via the sound card’s mixer, directly to the sound card’s output – bypassing android altogether. In Android terms, it would be called an “audio patch”, but this implementation is a hack rather than using the api correctly for it – which wasn’t previously an option. Apparently it is now, so at some point, I intend to use a proper Android audio patch to replace these hacks.

#13
  1. Init AOSP repo

repo init -u platform/manifest - Git at Google -b master

  1. Sync with manifest from 11.09.2018

repo sync -j8 -m 2018-09-11_15:49:35-pinned-manifest.xml

  1. Replace /device/linaro/hikey with

git clone https://gitlab.com/HiKey960-Car/android_device_linaro_hikey.git -b master_091118_car96

  1. Build

. build/envsetup.sh
lunch hikey960_car-userdebug
UBLOX_GPS_HAL=TRUE DMHD1000=TRUE HDMI_RES=“1920x1080@60” m -j4

Build fails:

out/soong/.intermediates/frameworks/base/packages/SettingsLib/SettingsLib/android_common/aapt2/packages/services/Car/car_product/overlay/frameworks/base/packages/SettingsLib/res/values_dimens.arsc.flat: error: failed to merge resource table.
error: failed parsing overlays.
19:15:58 ninja failed with: exit status 1

Have you seen such issue?

#14

Try deleting these two files;

packages/services/Car/car_product/overlay/frameworks/base/packages/SettingsLib/res/values/dimens.xml
packages/services/Car/car_product/overlay/frameworks/base/packages/SettingsLib/res/values/styles.xml
1 Like
#15

That was it. Thanks! All compiled.
I have used your kernel android-hikey-linaro-4.9_092518, but again it doesn’t boot.

I can’t attach boot logs, but what I can see there is

[ 66.533566] Bluetooth: hci0: request_firmware failed(errno -11) for ti-connectivity/TIInit_11.8.32.bts
[ 66.543047] Bluetooth: hci0: download firmware failed, retrying…

Full logs here https://ufile.io/l7ymv

#16

I can’t help you when you only give 2 lines that have no relevance.

#17

It works with boot.img build on prebuild Kernel (master).
Could it depend how boot.img is compiled?

Now I did like this:

restored prebuild images in device/linaro/hikey-kernel

rm out/target/product/hikey960/boot.img
lunch hikey960_car-userdebug
UBLOX_GPS_HAL=TRUE DMHD1000=TRUE HDMI_RES=“1920x1080@60” make bootimage -j4

When system boots now, blue LED is flashing before screen turns on, with your kernel, blue LED blinks once.

Second topic: Is there any additional actions to be done to make GPS work ?
I have U-blox 6010 GPS and after installing GPS Test App - it is able to find satellites. But when I use our Nav app, which probably uses Android API to get GPS location (it asks for permission and it is granted) - it seems it doesn’t get the location, with additional logs it says “No GPS available”.

#18

Sounds like the same failure to mount system partition. The blinking blue light is a distraction, ignore it. That just means that the Bluetooth firmware is being loaded, and that won’t happen until the system partition is mounted.

Regarding the GPS, look in the most recent few commits in the ublox directory for the specifications for the system property I’ve added to inform the HAL about where to find the GPS module. I had to add a physical addressing mechanism since there is a possibility of multiple usb devices racing for the second name, so on boot, the GPS could be named ttyACM0 or ttyACM1 or ttyACM7. And in fact I was getting randomly switching named with the GPS and my microcontroller.

If it isn’t obvious from the code, I’ll give you a better description of the parameter when I get into the office later.

#19

ublox_gps_hal directory ?

update: I have the code from below patch in place. I only have one device ttyACM0.
After some Nav app modifications I’m finally able to acquire GPS position.

#20

I told you to look in the commit history for the ublox hal path:

You see the third commit down?

Turns out you don’t even need to read the code. The details are in the commit’s description.