This is a cache of https://discuss.96boards.org/t/oe-using-qcom-kernel-mainline/937. It is a snapshot of the page at 2024-11-01T04:41:16.786+0000.
[OE] Using qcom kernel mainline - DragonBoard410c - 96Boards Forum

[OE] Using qcom kernel mainline

Hello all,

I have a quick question, I would like to try some features that I really need in the mainline of the kernel :
https://git.linaro.org/?p=landing-teams/working/qualcomm/kernel.git;a=shortlog;h=refs/heads/integration-linux-qcomlt

How can I pull the recipe linux-linaro-qcomlt-tracking_4.6.bb instead of linux-linaro-qcomlt_4.4.bb ?
There is some v4l2 drivers update provided by linaro and I’m really interested in.

Thanks to any suggestion ?

Jérôme.

this configuration is set in the $MACHINE configuration file, in conf/machine/include/apq8016.conf:

PREFERRED_PROVIDER_virtual/kernel ?= “linux-linaro-qcomlt”

you can override that in local.conf file

PREFERRED_PROVIDER_virtual/kernel = “linux-linaro-qcomlt-tracking”

If you need to make this change permanent, you will need to duplicate the machine .conf file.

Nice thanks Ndec. I will first give a try to make it work but for now I get the following error:

| /home/ubuntu/yocto/build-rpb-wayland/tmp-rpb_wayland-glibc/work/dragonboard_410c-oe-linux/linux-linaro-qcomlt-tracking/4.6-r0/build/arch/arm64/boot/dts/qcom/apq8016-sbc.dtb is missing qcom,msm-id?
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_deploy (log file is located at /home/ubuntu/yocto/build-rpb-wayland/tmp-rpb_wayland-glibc/work/dragonboard_410c-oe-linux/linux-linaro-qcomlt-tracking/4.6-r0/temp/log.do_deploy.118059)
ERROR: Task 70 (/home/ubuntu/yocto/build-rpb-wayland/conf/…/…/layers/meta-qcom/recipes-kernel/linux/linux-linaro-qcomlt-tracking_4.6.bb, do_deploy) failed with exit code ‘1’

Jérôme.

hi,

i just pushed a commit in krogoth (and master branch) of meta-qcom. I think this should fix the error above.

Allright so I went through another step and I have now the following error :
ERROR: rpb-weston-image-1.0-r0 do_rootfs: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: ‘exec_python_func() autogenerated’, lineno: 2, function: <module>
0001:
*** 0002:license_create_manifest(d)
0003:
File: ‘/home/ubuntu/yocto/build-rpb-wayland/conf/…/…/layers/openembedded-core/meta/classes/license.bbclass’, lineno: 48, function: license_create_manifest
0044: pkg_dic = {}
0045: for pkg in sorted(image_list_installed_packages(d)):
0046: pkg_info = os.path.join(d.getVar(‘PKGDATA_DIR’, True),
0047: ‘runtime-reverse’, pkg)
*** 0048: pkg_name = os.path.basename(os.readlink(pkg_info))
0049:
0050: pkg_dic[pkg_name] = oe.packagedata.read_pkgdatafile(pkg_info)
0051: if not “LICENSE” in pkg_dic[pkg_name].keys():
0052: pkg_lic_name = “LICENSE_” + pkg_name
Exception: OSError: [Errno 2] No such file or directory: ‘/home/ubuntu/yocto/build-rpb-wayland/tmp-rpb_wayland-glibc/sysroots/dragonboard-410c/pkgdata/runtime-reverse/kernel-4.4.9+linaro’

ERROR: rpb-weston-image-1.0-r0 do_rootfs: Function failed: license_create_manifest
ERROR: Logfile of failure stored in: /home/ubuntu/yocto/build-rpb-wayland/tmp-rpb_wayland-glibc/work/dragonboard_410c-oe-linux/rpb-weston-image/1.0-r0/temp/log.do_rootfs.2793
ERROR: Task 9 (/home/ubuntu/yocto/build-rpb-wayland/conf/…/…/layers/meta-rpb/recipes-samples/images/rpb-weston-image.bb, do_rootfs) failed with exit code ‘1’

It seems logic because the kernel version is now 4.7.0 but where is it specified ? Could I change that ?

Thanks,

Jérôme.

Ok my bad I had to nuke the files in deploy/ipk/dragonboard_410c resulting of the previous build I did…
Looks good now, just have to test it…

@ndec,

Hello Nicolas,

Have you done anything to the boot.img generated in the OE to make it works ? I have never been able to boot the db with any of the boot.img that I built.
Could there be something that I’m not doing?

Here is the link of my boot with kernel 4.7.0 : https://drive.google.com/file/d/0B1GJmvi-rkKRM2tkRmFsckU4eDQ/view?usp=sharing

Jérôme.

the boot.img that OE generates should work. the binary that we provide here:

http://builds.96boards.org/snapshots/reference-platform/openembedded/krogoth/dragonboard-410c/

come directly from the OE deploy folder without any change, and the images are being booted in he board farm. E.g. this LAVA job :

https://validation.linaro.org/scheduler/job/1135317

tested the binary files form this build :

http://builds.96boards.org/snapshots/reference-platform/openembedded/krogoth/dragonboard-410c/rpb/23

what issue are you seeing with your image? Do you have the serial console log?

Hi so following is what I got :

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.0-00261
S - IMAGE_VARIANT_STRING=HAAAANAAA
S - OEM_IMAGE_VERSION_STRING=C-BPATTH
S - Boot Config, 0x000002e3
S - Core 0 Frequency, 0 MHz
B - 1547 - PBL, Start
B - 3493 - bootable_media_detect_entry, Start
B - 117050 - bootable_media_detect_success, Start
B - 117055 - elf_loader_entry, Start
B - 119586 - auth_hash_seg_entry, Start
B - 119796 - auth_hash_seg_exit, Start
B - 134401 - elf_segs_hash_verify_entry, Start
B - 193277 - PBL, End
B - 200080 - SBL1, Start
B - 263093 - pm_device_init, Start
D - 14792 - pm_device_init, Delta
B - 278495 - boot_flash_init, Start
D - 0 - boot_flash_init, Delta
B - 282521 - boot_config_data_table_init, Start
D - 19062 - boot_config_data_table_init, Delta - (0 Bytes)
B - 306159 - CDT version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:0
B - 312350 - sbl1_ddr_set_params, Start
B - 316071 - cpr_init, Start
D - 0 - cpr_init, Delta
B - 321683 - Pre_DDR_clock_init, Start
D - 213 - Pre_DDR_clock_init, Delta
D - 0 - sbl1_ddr_set_params, Delta
B - 334188 - pm_driver_init, Start
D - 6832 - pm_driver_init, Delta
B - 349682 - clock_init, Start
D - 30 - clock_init, Delta
B - 359839 - Image Load, Start
D - 24888 - QSEE Image Loaded, Delta - (460664 Bytes)
B - 384757 - Image Load, Start
D - 396 - SEC Image Loaded, Delta - (2048 Bytes)
B - 391955 - sbl1_efs_handle_cookies, Start
D - 61 - sbl1_efs_handle_cookies, Delta
B - 399733 - Image Load, Start
D - 13511 - QHEE Image Loaded, Delta - (51952 Bytes)
B - 413275 - Image Load, Start
D - 13450 - RPM Image Loaded, Delta - (149492 Bytes)
B - 426725 - Image Load, Start
D - 12414 - APPSBL Image Loaded, Delta - (487604 Bytes)
B - 439169 - QSEE Execution, Start
D - 61 - QSEE Execution, Delta
B - 444842 - SBL1, End
D - 247141 - SBL1, Delta
S - Flash Throughput, 112000 KB/s (1151760 Bytes, 10217 us)
S - DDR Frequency, 400 MHz
Android Bootloader - UART_DM Initialized!!!
[0] welcome to lk

[10] platform_init()
[10] target_init()
[40] SDHC Running in HS200 mode
[60] Done initialization of the card
[70] pm8x41_get_is_cold_boot: cold boot
[70] No ‘frp’ partition found
[70] Not able to search the panel:
[80] Display not enabled for 24 HW type
[80] Target panel init not found!
[80] pm8x41_get_is_cold_boot: cold boot
[90] partition misc doesn’t exist
[90] error in emmc_recovery_init
[90] Unable to locate /bootselect partition
[100] No ‘misc’ partition found
[100] Error reading MISC partition
[100] failed to get ffbm cookie[110] use_signed_kernel=0, is_unlocked=0, is_tampered=0.
[110] Loading boot image (18528256): start
[230] Loading boot image (18528256): done
[370] DTB Total entry: 1, DTB version: 3
[370] Using DTB entry 0x000000f7/00000000/0x00000018/0 for device 0x000000f7/00010000/0x00010018/0
[380] Using pmic info 0xb/0x0/0x0/0x0 for device 0x2000b/0x0/0x0/0x0
[390] target_display_panel_node:510: hw_id=24 panel_name=""
[390] cmdline: root=/dev/mmcblk0p10 rw rootwait console=ttyMSM0,115200n8 androidboot.emmc=true androidboot.serialno=11d82320 androidboot.baseband=apq mdss_mdp.panel=0:dsi:0:
[410] Updating device tree: start
[500] Updating device tree: done
[510] booting linux @ 0x80080000, ramdisk @ 0x82000000 (22), tags/device tree @ 0x81e00000
[510] Jumping to kernel via monitor

And then nothing is happening. No Led blinking either (well it is quite normal if the kernel is not loaded).
I’m a bit confused here when comparing a working boot.img and my boot.img.
There is something that should talk to you hopefully…

Thanks, Jérôme

Wondering if the problem does not come from the next version of DTB (version3).
I used the revision you pushed and this one works ok but when I try to used the revision of “qcomlt-v4.7” branch it doesn’t work. Some evolution seems to be necessary I guess.

hi,

sorry about the delay, i was travelling…

I am trying to understand what’s going on here… I have tried 4.7 branch and it worked fine. I have tried your boot image and it doesn’t boot…

can you please share your meta-qcom patches so that I can try to reproduce here?

Note that I am planning to update the kernel to 4.7 this week in meta-qcom… so we need to figure this out anyways…

thx

Hi Ndec,

Thanks to taking care of that. I don’t have any specific patch for the meta-qcom because I did some ugly patch but here is my meta-qcom (i’m trying to build the rpb-weston-image ):
https://drive.google.com/file/d/0B1GJmvi-rkKRUWcwUjdmQkZSUVU/view?usp=sharing
I haven’t pull the last update you did 20hours ago. I will give it a try now.
For the kernel I’m trying to use the following revision :
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/028d7ad1aff413c8dff2c53202ee709dd87aeb48

Jérôme.

@ndec,

Hello ndec, any news on your side concerning this matter? Are you able to reproduce the problem ?

Thanks,

Jérôme.

Hi,

I tried again to start from scratch with the new release you did the last week allowing to build the kernel v4.7.
I haven’t patch anything, I just build the image rpb-minimal-image.
But I got the exact same problem, nothing happening after instruction “Jumping to kernel via monitor”.

How did you build your boot.img 4.7? What procedure do you use?

Jérôme.

hi,

i can reproduce now. I built 4.7 kernel with meta-qcom for db410c, and i am seeing the same as you are seeing.

When I built the same kernel separately in my regular build environment, i am seeing different results. from there, i need to investigate more…

however please note that this kernel branch gets much less testing (and features) than the release branch… for the short term, we will be using:

  • 4.4 for Db410c until December release, then 4.9
  • 4.7 for DB820c, but 4.9 for the December release, and for DB820c we will keep upgrading the kernel until ~June.

Hi,

What is the latest kernel version that can be built for DragonBoard 410c?
Thanks.

Regards,
Yan Lin

it depends on what you want/need. the latest kernel that we support for ‘releases’ is 4.4 (e.g. the release/qcomlt-4.4 branch in our git tree). The agreement we have done with QC, is that we will upgrade the ‘release’ kernel once a year, typically to new LTS kernel release. So we will upgrade to 4.9 LTS when it’s available. Our next release will be around mid Dec with 4.4 and it will be the last one with 4.4. The next release after that will be around March with 4.9.

In the release branch we try to make sure everything works. but you can use the mainline kernel directly and cherry pick the few ‘things’ that you need. Mainline boots fine and more features get enabled in each release…

@ndec, thanks for the info. In the conversations above, you mentioned about 4.7 kernel built on db410c.

How can I get 4.7 kernel on db410c?

Can I use the OE flow mentioned here: https://github.com/Linaro/documentation/blob/master/Reference-Platform/RPTest/ConsumerEdition/DragonBoard-410c/InstallOERPB-16.03.md by overriding the local.conf file with PREFERRED_PROVIDER_virtual/kernel = “linux-linaro-qcomlt-tracking”?

Thanks again.

Regards,
Yan Lin Aung

as i said, if you use 4.7 (mainline) you will be on your own, and will need to cherry pick patches from more recent kernel and/or from the release branch.

the current tracking branch is still based on 4.7, but if you read the posts in that thread, it is known to not work.

Your best bet to hope to get any support is to either use the release branch or to work with the very latest kernel -rc release (or linux-next). This is where all our efforts are focused (upstream and release). anything in between will be hard to support on our end.

@ndec, thanks again for your explanation.
I will look forward to the official 4.9 kernel release for db410c.
It will be around March 2017, right?
Thanks.

Regards,
Yan Lin Aung