BSP Team Bug Triage

From Yocto Project
Jump to: navigation, search

Contents

New Team bugs (No Priority)

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      
IDSummaryAssigneeStatusProductSeverityPMilestoneWhiteboard
 0       

New BSP bugs (No milestone)

IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
 0       
IDSummarySeverityPMilestoneAssigneeStatusWhiteboardE
 0       

High/Medium+ Bugs

IDSummary (15 tasks) SeverityPMilestoneAssigneeStatusWhiteboardE
12602*
12602 Model:NUC6i7KYK
[meta-intel 2.4.2 rc2] Error Present in dmesg logs for core-image-lsb-sdk image on NUC6normalMedium+2.4.4Anuj MittalACCEPTED
12638*(reproducibility) pulseaudio packages contain build host referencesnormalMedium+2.6 M1Juro BystrickyIN PROGRESS IMPLEMENTATIONreproducibility
12666*
12666 Please try this on a NUC to check.
[2.5 M3 RC1] BSP-QEMU:core-image-sato-sdk-genericx86-64.hddimg unable to connect to console with serial on Minnowboard TurbotnormalMedium+2.6 M1Stephano CetolaNEW
12748*
12748 Can I provide any additional information or do any further testing to help resolve this bug?
Recipe hello-mod from meta-skeleton does not buildmajorMedium+2.6 M1Stephano CetolaACCEPTED
12776*
12776

(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > Leo, I tried this but couldn't reproduce. Can you share more details please? > > > > > > When the installer shows: > > > > > > 'Please select an install target or press n to exit ( sda ):' > > > > > > did you type sda and then enter? > > > > > > Does the script hang after that? > > > > > > Right. Actually I am using other non-oe-core layers, but I doubt this can > > affect the resulting image. Attached are the steps to reproduce it. Just > > ignore the meta-pnp part (meta-pnp is an layer that we are using to measure > > performance on a Poky OS, the latter just adds some meta-oe and meta-python > > packages). > > The steps mention that you're using wic create and are using your own wks > file and then flashing the wic created image to usb? >

Basically I worked around it booting the wic, then dd from stick to hard disk.

> That image won't have install target. Aren't you using the .hddimg that is > created for you when building core-image-pnp with intel-corei7-64 MACHINE > name?

The problem is with the hddimg, not wic. Once I dd a sick with the hddimg and boot the NUC, choose the installer, shortly after, it will hang.
hddimg installer hangs on sumonormalMedium+2.6 M2Anuj MittalACCEPTED1
12804*
12804

STATUS - FAILED

ENVIRONMENT - VMWare(14.1.1) on Ubuntu OS (16.04)

BUILD: 2.6_M1.rc1 - ddbd7b0cd6580ee26e11aa87e426fb294b372d64

STEPS TO REPRODUCE :
- Boot the build appliance image in VMWare
- configure the proxy setting,
  export http_proxy=http://proxy.png.intel.com:911
  export https_proxy=https://proxy.png.intel.com:911
  export ftp_proxy=http://proxy.png.intel.com:911
  export socks_server=proxy.png.intel.com:1080
  export ALL_PROXY=socks://proxy.png.intel.com:1080
- run "bitbake core-image-minimal"

ACTUAL RESULT:

Getting below error,
WARNING: Host distribution "poky-2.5+snapshot-20180607" has not been validated with this version of the build system; you may possibly experience unexpected failure.

It is recommended that you use a tested distribution. ERROR: OE-core's config sanity checker detected a potential misconfiguraition.

     Either fix the cause of this error or at your own risk disable the checker (see sanity.conf)
     Following is the list of potential problems / advisories:
     Fetcher failure for URL: 'https://www.example.com/' . URL https://www.example.com/ doesn't work.
     Please ensure your host's network is configured correctly.
     or set BB_NO_NETWORK = "1" to disable network access if
     all required sources are on local disk.

Summary: There was 1 WARNING message shown Summary: There was 1 ERROR message shown, returning a non-zero exit code.

EXPECTED RESULT :

"bitbake core-image-minimal" should run and build successfully.

REGRESSION :

Regression done with 2.4.3.rc2 and 2.5. Both these images booted in VMWare and proxy can be configured. bitbake core-image-minimal is running successfully.
[QA 2.6 M1 rc1 ][Build Appliance]: proxy issue in VM warenormalMedium+2.6 M2Anuj MittalNEW
12806*
12806

This works fine for me in my builds.

I need source/build based reproducers, since I can't debug these images.
[2.6 M1 rc1 ][BSP][Test Run 9708]: ppc Image is not booting on qemunormalMedium+2.6 M2Anuj MittalNEW
12404*
12404 wic rm does not currently remove directories, nor does it support the -r flag
wic rm should remove directories and support the -r flagnormalMedium+2.99Amber ElliotNEW4
12755*
12755

As part of the work for 2.5 we made some changes in order to move the bootloader configuration out to separate recipes (grub-bootconf and systemd-bootconf); at least systemd-bootconf is reading the APPEND variable which is used to set the kernel command line. Unfortunately this is problematic in that the previous assumption was that APPEND was only read in the image context (and therefore could be effectively set from there). The following change is an example:

 http://cgit.openembedded.org/openembedded-core/commit/?id=cfc09de06ecc12bb42181004689e881c75072665

Cal suggested that the separate configuration wasn't used by default and thus this shouldn't be a major problem yet - I wasn't clear on the details though.

Somehow this needs to be reconciled.
Separate boot config recipes are at odds with setting APPEND at the image levelnormalMedium+2.99Anuj MittalNEW
12584*
12584

Currently, the generic EFI boot method using the following assume root=/dev/sda2 or similar:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks/efi-bootdisk.wks.in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd-bootconf_1.00.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/grub/grub-bootconf_1.00.bb

Using /dev/sda and such is not a reliable way to boot, as it depends on the install media enumerating to a certain value. Instead random UUIDs should be used.

This will require both the -bootconf recipes and wic to know the same random value. This value also needs to be saved in sstate, else issues will arise when rebuilding and doing package upgrades.

The current path to explore to accomplish this is as follows: 1) modify wic to take a file containing a UUID as input for its UUID creation 2) merge the -bootconf recipes into one recipe with multiple packages. This package would also deploy the UUID file for consumption. 3) modify efi-bootdisk.wks.in to use the new wic functionality and UUID file.

This would allow all bootloaders and wic to know the same UUID, and since it uses deploy should work with sstate. The new bootconf recipe would need to be extensible to support any arbitrary bootloader as well.
Generic EFI booting needs to support random UUIDsnormalMedium+2.99California SullivanNEW
11385*
11385

Moving to Joshua

seems like this should be the documentation bug for the solution in Bug 11097's comments.
poky-container: clarify that meta-data should be checked out using native tools that run the host and not with tools in containernormalMedium+2.99Stephano CetolaNEW1
11775*
11775 This is a bug. It's also a simple change and should make M4.
oe-init-build-env should check for dash and throw a meaningful errornormalMedium+2.99Stephano CetolaIN PROGRESS IMPLEMENTATION1
12409*
12409

We can make sure that Wic is documented properly in the YP manual set after the Wic help output is properly formatted as suggested below.

Scott
Add information removed from wic "help" to wic documentationnormalMedium+2.99Stephano CetolaACCEPTED
12561*
12561

This should cover when customers should use which Linux (linux-intel vs linux-yocto), which versions of meta-intel go with which versions of poky, and what versions have been QA'd. It could also show current QA status.

It should be fashioned after the freescale community bsp.

We should also clean up information like this:

https://wiki.yoctoproject.org/wiki/Meta-intel_Release_Process
Create a community resource for meta-intelnormalMedium+2.99Stephano CetolaACCEPTED
12408*
12408 Currently just waiting on the patch for 12205 to be accepted, latest version submitted 1/30.
Update wic documentation to remove outdated "help" referencesnormalMedium+FutureAmber ElliotIN PROGRESS IMPLEMENTATION
 15       

NEEDINFO

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

REOPENDED

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboard
 0      

Old Milestone

IDSummary (8 tasks) AssigneeStatusSeverityPMilestoneWhiteboard
12205*
12205

Ok Amber. I will wait until this is merged so I can play with it and then document it in that section where I tell about the wic command.

Thanks,

Scott
'wic help' / 'wic --help' output is not user friendly. Needs to be redoneStephano CetolaIN PROGRESS REVIEWnormalMedium2.6 M1
12602*
12602 Model:NUC6i7KYK
[meta-intel 2.4.2 rc2] Error Present in dmesg logs for core-image-lsb-sdk image on NUC6Anuj MittalACCEPTEDnormalMedium+2.4.4
12638*(reproducibility) pulseaudio packages contain build host referencesJuro BystrickyIN PROGRESS IMPLEMENTATIONnormalMedium+2.6 M1reproducibility
12666*
12666 Please try this on a NUC to check.
[2.5 M3 RC1] BSP-QEMU:core-image-sato-sdk-genericx86-64.hddimg unable to connect to console with serial on Minnowboard TurbotStephano CetolaNEWnormalMedium+2.6 M1
12748*
12748 Can I provide any additional information or do any further testing to help resolve this bug?
Recipe hello-mod from meta-skeleton does not buildStephano CetolaACCEPTEDmajorMedium+2.6 M1
12776*
12776

(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > Leo, I tried this but couldn't reproduce. Can you share more details please? > > > > > > When the installer shows: > > > > > > 'Please select an install target or press n to exit ( sda ):' > > > > > > did you type sda and then enter? > > > > > > Does the script hang after that? > > > > > > Right. Actually I am using other non-oe-core layers, but I doubt this can > > affect the resulting image. Attached are the steps to reproduce it. Just > > ignore the meta-pnp part (meta-pnp is an layer that we are using to measure > > performance on a Poky OS, the latter just adds some meta-oe and meta-python > > packages). > > The steps mention that you're using wic create and are using your own wks > file and then flashing the wic created image to usb? >

Basically I worked around it booting the wic, then dd from stick to hard disk.

> That image won't have install target. Aren't you using the .hddimg that is > created for you when building core-image-pnp with intel-corei7-64 MACHINE > name?

The problem is with the hddimg, not wic. Once I dd a sick with the hddimg and boot the NUC, choose the installer, shortly after, it will hang.
hddimg installer hangs on sumoAnuj MittalACCEPTEDnormalMedium+2.6 M2
12804*
12804

STATUS - FAILED

ENVIRONMENT - VMWare(14.1.1) on Ubuntu OS (16.04)

BUILD: 2.6_M1.rc1 - ddbd7b0cd6580ee26e11aa87e426fb294b372d64

STEPS TO REPRODUCE :
- Boot the build appliance image in VMWare
- configure the proxy setting,
  export http_proxy=http://proxy.png.intel.com:911
  export https_proxy=https://proxy.png.intel.com:911
  export ftp_proxy=http://proxy.png.intel.com:911
  export socks_server=proxy.png.intel.com:1080
  export ALL_PROXY=socks://proxy.png.intel.com:1080
- run "bitbake core-image-minimal"

ACTUAL RESULT:

Getting below error,
WARNING: Host distribution "poky-2.5+snapshot-20180607" has not been validated with this version of the build system; you may possibly experience unexpected failure.

It is recommended that you use a tested distribution. ERROR: OE-core's config sanity checker detected a potential misconfiguraition.

     Either fix the cause of this error or at your own risk disable the checker (see sanity.conf)
     Following is the list of potential problems / advisories:
     Fetcher failure for URL: 'https://www.example.com/' . URL https://www.example.com/ doesn't work.
     Please ensure your host's network is configured correctly.
     or set BB_NO_NETWORK = "1" to disable network access if
     all required sources are on local disk.

Summary: There was 1 WARNING message shown Summary: There was 1 ERROR message shown, returning a non-zero exit code.

EXPECTED RESULT :

"bitbake core-image-minimal" should run and build successfully.

REGRESSION :

Regression done with 2.4.3.rc2 and 2.5. Both these images booted in VMWare and proxy can be configured. bitbake core-image-minimal is running successfully.
[QA 2.6 M1 rc1 ][Build Appliance]: proxy issue in VM wareAnuj MittalNEWnormalMedium+2.6 M2
12806*
12806

This works fine for me in my builds.

I need source/build based reproducers, since I can't debug these images.
[2.6 M1 rc1 ][BSP][Test Run 9708]: ppc Image is not booting on qemuAnuj MittalNEWnormalMedium+2.6 M2
 8      

YP 2.5 remaining BSP Team Enhancements

IDSummaryAssigneeStatusSeverityPMilestoneWhiteboardE
 0       

Amber Bugs

IDSummary (8 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
10726*
10726 Returning version to 2.3.
Add a test to verify if oe-pkgdata-util print help when no parameters specifiedAmber ElliotACCEPTEDenhancementMedium2.992
11279*
11279

In image.bbclass: get_rootfs_size()

   rootfs_alignment = int(d.getVar('IMAGE_ROOTFS_ALIGNMENT'))
   overhead_factor = float(d.getVar('IMAGE_OVERHEAD_FACTOR'))
   rootfs_req_size = int(d.getVar('IMAGE_ROOTFS_SIZE'))
   rootfs_extra_space = eval(d.getVar('IMAGE_ROOTFS_EXTRA_SPACE'))
   rootfs_maxsize = d.getVar('IMAGE_ROOTFS_MAXSIZE')
   image_fstypes = d.getVar('IMAGE_FSTYPES') or 
   initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES') or 
   initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
ROOTFS_SIZE gets set with the value of the above function.
wic: honor IMAGE_ROOTFS_EXTRA_SPACE et alAmber ElliotNEWenhancementMedium2.991
11977*
11977 We should print a message to suggest which modules are missing.
bitbake -g -u taskexp <target> raises an import exceptionAmber ElliotNEWminorMedium2.993
12018*
12018 The output of bitbake --help should be grouped to make it easier to read. For example showing first the options that a normal user would use (-C --runall etc), then debugging options, then internal flags (or even hide those behind --help-internal?)
Help output should be groupedAmber ElliotNEWenhancementMedium2.99
12189*
12189

One of the things you would commonly want to cp into a wic image using wic cp is lib/modules/kernel-version. This would require a recursive copy. e.g.

wic cp modules--4.x.x/ wicimage:/lib/modules/
wic cp should support recursive copiesAmber ElliotNEWenhancementMedium+2.994
12404*
12404 wic rm does not currently remove directories, nor does it support the -r flag
wic rm should remove directories and support the -r flagAmber ElliotNEWnormalMedium+2.994
12169*
12169 IoTG is excited about this. They currently scp files off their booted image, but this would be a great help to them sometime in the future. No rush though.
wic cp allows me to cp a file into a wic partition, it should let me cp one out as well.Amber ElliotNEWenhancementLowFuture3
12408*
12408 Currently just waiting on the patch for 12205 to be accepted, latest version submitted 1/30.
Update wic documentation to remove outdated "help" referencesAmber ElliotIN PROGRESS IMPLEMENTATIONnormalMedium+Future
 8       

Anuj Bugs

IDSummary (16 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12602*
12602 Model:NUC6i7KYK
[meta-intel 2.4.2 rc2] Error Present in dmesg logs for core-image-lsb-sdk image on NUC6Anuj MittalACCEPTEDnormalMedium+2.4.4
12763[Meta-Intel 2.5 M4 RC1] Error present in parselog for core-image-sato-sdk image on NUC7Anuj MittalNEWnormalMedium2.61
12764*
12764

NOTE: ====================================================================== NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) NOTE: ---------------------------------------------------------------------- NOTE: Traceback (most recent call last):

 File "/data/pankajsx/sato_poky_regression/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/data/pankajsx/sato_poky_regression/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
   return func(*args, **kwargs)
 File "/data/pankajsx/sato_poky_regression/poky/meta/lib/oeqa/runtime/cases/parselogs.py", line 363, in test_parselogs
   self.assertEqual(errcount, 0, msg=self.msg)

AssertionError: 1 != 0 : Log: /data/pankajsx/sato_poky_regression/poky/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato-sdk/1.0-r0/dmesg_output.log


Central error: [ 12.485733] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=1484 end=1500) time 279398 us, min 1073, max 1079, scanline start 1115, end 850

[ 12.419930] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 12.423864] RIP: 0033:0x3a680e98f7 [ 12.426083] RSP: 002b:00007ffea27f5ba8 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [ 12.432773] RAX: ffffffffffffffda RBX: 00007ffea27f5bfc RCX: 0000003a680e98f7 [ 12.438893] RDX: 00007ffea27f5be0 RSI: 00000000c06864a2 RDI: 000000000000000d [ 12.445046] RBP: 00007ffea27f5be0 R08: 0000000000000000 R09: 00000000017879c0 [ 12.451226] R10: 00007ffea27f5cb0 R11: 0000000000003246 R12: 00000000c06864a2 [ 12.457404] R13: 000000000000000d R14: 0000000000d8e950 R15: 0000000000c336b0 [ 12.463567] Code: 5b 41 5c 41 5d 5d c3 45 84 ed 48 c7 c0 c6 17 55 c0 44 89 e2 48 c7 c6 bc 17 55 c0 48 c7 c7 cf 17 55 c0 48 0f 44 f0 e8 73 b1 c0 cc <0f> 0b 83 2d 4d 2e 0c 00 01 5b 41 5c 41 5d 5d c3 66 90 0f 1f 44 [ 12.482103] ---[ end trace a16ea3392fc40ee1 ]--- [ 12.485733] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=1484 end=1500) time 279398 us, min 1073, max 1079, scanline start 1115, end 850 [ 12.756094] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1:1.0/0003:046D:C06A.0003/input/input13 [ 12.768483] hid-generic 0003:046D:C06A.0003: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:14.0-4.1/input0 [ 12.784175] input: CHICONY HP Basic USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.2/1-4.2.3/1-4.2.3:1.0/0003:03F0:0024.0004/input/input14 [ 12.849420] hid-generic 0003:03F0:0024.0004: input: USB HID v1.10 Keyboard [CHICONY HP Basic USB Keyboard] on usb-0000:00:14.0-4.2.3/input0 [ 13.120297] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1:1.0/0003:046D:C06A.0005/input/input15 [ 13.132888] hid-generic 0003:046D:C06A.0005: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:14.0-4.1/input0 [ 13.148023] input: CHICONY HP Basic USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.2/1-4.2.3/1-4.2.3:1.0/0003:03F0:0024.0006/input/input16 [ 13.213399] hid-generic 0003:03F0:0024.0006: input: USB HID v1.10 Keyboard [CHICONY HP Basic USB Keyboard] on usb-0000:00:14.0-4.2.3/input0 [ 13.520117] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1:1.0/0003:046D:C06A.0007/input/input17 [ 13.532223] hid-generic 0003:046D:C06A.0007: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:14.0-4.1/input0

1 errors found in logs.

NOTE: ---------------------------------------------------------------------- NOTE: Ran 11 tests in 15.765s NOTE: FAILED NOTE: (failures=1) RESULTS: RESULTS - logrotate.LogrotateTest.test_1_logrotate_setup - Testcase 1544: PASSED RESULTS - logrotate.LogrotateTest.test_2_logrotate - Testcase 1542: PASSED RESULTS - parselogs.ParseLogsTest.test_parselogs - Testcase 1059: FAILED RESULTS - ping.PingTest.test_ping - Testcase 964: PASSED RESULTS - rpm.RpmBasicTest.test_rpm_help - Testcase 960: PASSED RESULTS - rpm.RpmBasicTest.test_rpm_query - Testcase 191: PASSED RESULTS - rpm.RpmInstallRemoveTest.test_check_rpm_install_removal_log_file_size - Testcase 195: PASSED RESULTS - rpm.RpmInstallRemoveTest.test_rpm_install - Testcase 192: PASSED RESULTS - rpm.RpmInstallRemoveTest.test_rpm_query_nonroot - Testcase 1096: PASSED RESULTS - rpm.RpmInstallRemoveTest.test_rpm_remove - Testcase 194: PASSED RESULTS - ssh.SSHTest.test_ssh - Testcase 224: PASSED SUMMARY: core-image-sato-sdk () - Ran 11 tests in 15.767s core-image-sato-sdk - FAIL - Required tests failed ERROR: core-image-sato-sdk - FAILED - check the task log and the ssh log DEBUG: Python function do_testimage finished ERROR: Function failed: do_testimage Machine information:

Machine name: intel-corei7-64 CPU: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz Arch: x86_64 Physical cores: 4 Logical cores: 8

[Meta-Intel 2.5 M4 RC1] Error present in parselog for core-image-sato-sdk image on NUC6Anuj MittalNEWnormalMedium2.61
12776*
12776

(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > Leo, I tried this but couldn't reproduce. Can you share more details please? > > > > > > When the installer shows: > > > > > > 'Please select an install target or press n to exit ( sda ):' > > > > > > did you type sda and then enter? > > > > > > Does the script hang after that? > > > > > > Right. Actually I am using other non-oe-core layers, but I doubt this can > > affect the resulting image. Attached are the steps to reproduce it. Just > > ignore the meta-pnp part (meta-pnp is an layer that we are using to measure > > performance on a Poky OS, the latter just adds some meta-oe and meta-python > > packages). > > The steps mention that you're using wic create and are using your own wks > file and then flashing the wic created image to usb? >

Basically I worked around it booting the wic, then dd from stick to hard disk.

> That image won't have install target. Aren't you using the .hddimg that is > created for you when building core-image-pnp with intel-corei7-64 MACHINE > name?

The problem is with the hddimg, not wic. Once I dd a sick with the hddimg and boot the NUC, choose the installer, shortly after, it will hang.
hddimg installer hangs on sumoAnuj MittalACCEPTEDnormalMedium+2.6 M21
12804*
12804

STATUS - FAILED

ENVIRONMENT - VMWare(14.1.1) on Ubuntu OS (16.04)

BUILD: 2.6_M1.rc1 - ddbd7b0cd6580ee26e11aa87e426fb294b372d64

STEPS TO REPRODUCE :
- Boot the build appliance image in VMWare
- configure the proxy setting,
  export http_proxy=http://proxy.png.intel.com:911
  export https_proxy=https://proxy.png.intel.com:911
  export ftp_proxy=http://proxy.png.intel.com:911
  export socks_server=proxy.png.intel.com:1080
  export ALL_PROXY=socks://proxy.png.intel.com:1080
- run "bitbake core-image-minimal"

ACTUAL RESULT:

Getting below error,
WARNING: Host distribution "poky-2.5+snapshot-20180607" has not been validated with this version of the build system; you may possibly experience unexpected failure.

It is recommended that you use a tested distribution. ERROR: OE-core's config sanity checker detected a potential misconfiguraition.

     Either fix the cause of this error or at your own risk disable the checker (see sanity.conf)
     Following is the list of potential problems / advisories:
     Fetcher failure for URL: 'https://www.example.com/' . URL https://www.example.com/ doesn't work.
     Please ensure your host's network is configured correctly.
     or set BB_NO_NETWORK = "1" to disable network access if
     all required sources are on local disk.

Summary: There was 1 WARNING message shown Summary: There was 1 ERROR message shown, returning a non-zero exit code.

EXPECTED RESULT :

"bitbake core-image-minimal" should run and build successfully.

REGRESSION :

Regression done with 2.4.3.rc2 and 2.5. Both these images booted in VMWare and proxy can be configured. bitbake core-image-minimal is running successfully.
[QA 2.6 M1 rc1 ][Build Appliance]: proxy issue in VM wareAnuj MittalNEWnormalMedium+2.6 M2
12806*
12806

This works fine for me in my builds.

I need source/build based reproducers, since I can't debug these images.
[2.6 M1 rc1 ][BSP][Test Run 9708]: ppc Image is not booting on qemuAnuj MittalNEWnormalMedium+2.6 M2
9789*
9789 Moving this to 2.5M1. I will backport to Rocko (2.4.1) if needed.
systemd rootfs-postprocess command should check staticidsAnuj MittalACCEPTEDnormalMedium2.992
11432*
11432 bug 11432 requires the same feature as the one reported.
patchtest-oe: detect patches being added without modifying SRC_URIAnuj MittalNEWenhancementMedium2.991
12086*
12086 I'm not familiar with autobuilder, can anyone do it, please ?
Create an autobuilder script to test for long path errorsAnuj MittalNEWenhancementMedium2.993
12187*
12187

BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: genericx86-64_NUC NUC Model: NUC6i5SYH IMAGES: core-image-sato-sdk.wic, core-image-sato-sdk.hddimg

The "snd_hda_codec_hdmi" parselog errors continue appearing in 2.4 RC3 on automatic BSP testing for genericx86-64 images in NUC (in both, wic and hddimg formats). For more reference, I have attached the log file with more details about the execution using the hddimg version.

This is an example of the errors that appear:

Central error: [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16

[ 1.448566] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.449571] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.449609] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.452014] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452015] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452015] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452016] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.452017] snd_hda_intel 0000:00:1f.3: Too many HDMI devices [ 1.452017] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y [ 1.453193] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present [ 1.453224] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 [ 1.453793] snd_hda_codec_generic hdaudioC0D2: ignore pin 0x7, too many assigned pins [ 1.453795] snd_hda_codec_generic hdaudioC0D2: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [ 1.453796] snd_hda_codec_generic hdaudioC0D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453796] snd_hda_codec_generic hdaudioC0D2: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1.453797] snd_hda_codec_generic hdaudioC0D2: mono: mono_out=0x0 [ 1.453798] snd_hda_codec_generic hdaudioC0D2: dig-out=0x5/0x6 [ 1.453799] snd_hda_codec_generic hdaudioC0D2: inputs: [ 1.455463] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input4 [ 1.455526] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input5

[ 1.455598] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
not audio- play (wav) with HDMI, 2.4Anuj MittalNEWnormalMedium2.993
12217*
12217

It looks to me like this did get added at least to IMAGE_FSTYPES:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c44980abaf4ef3756597c0c5b51678253a56a5f5

(Note that you still need the meta-filesystems layer in your configuration in order to provide the required f2fs-tools recipe.)
Support F2FSAnuj MittalNEWenhancementMedium2.994
12320*
12320

The multiple-kernel built and deployed in one image from BZ#11363 leads to the next enhancement request: enabling multiple kernels in systemd-boot or grub-efi (or other) boot menu.

This is fairly common in mainline Linux distributions and an increasingly frequent request from our customers, especially during development and integration.

In addition to enabling the multiple kernels, while we are at it we should enable multiple kernel command lines in the menu (different options for the same kernel binary).

An example use case is to compare latency/performance of (1) "standard" (e.g. 4.9.47), (2)"stable preempt_rt" (e.g. 4.9.47-rt37) and (3) "rt-devel" (e.g. 4.13.10-rt3) kernels (different binaries) without and with (4,5,6) debug enabled (command line argument).

The three kernels (1,2,3) should be discoverable at image creation time (using, e.g. KERNEL_PACKAGE_NAME[]) and the boot menu should be able to be "auto" populated. The additional command line argument entries (4,5,6) would clearly need to be manually configured by a different mechanism.
Enable multiple kernels and multiple kernel command lines in systemd-boot, grub-efi menuAnuj MittalNEWenhancementMedium2.99
12755*
12755

As part of the work for 2.5 we made some changes in order to move the bootloader configuration out to separate recipes (grub-bootconf and systemd-bootconf); at least systemd-bootconf is reading the APPEND variable which is used to set the kernel command line. Unfortunately this is problematic in that the previous assumption was that APPEND was only read in the image context (and therefore could be effectively set from there). The following change is an example:

 http://cgit.openembedded.org/openembedded-core/commit/?id=cfc09de06ecc12bb42181004689e881c75072665

Cal suggested that the separate configuration wasn't used by default and thus this shouldn't be a major problem yet - I wasn't clear on the details though.

Somehow this needs to be reconciled.
Separate boot config recipes are at odds with setting APPEND at the image levelAnuj MittalNEWnormalMedium+2.99
2552*
2552 This could be similar to phoronix work also
x32: identify workload & collect benchmark data to show value of x32Anuj MittalNEWnormalLowFuture6
3359*
3359 I have a version that doesn't segfault, but doesn't find the debug info it needs. Need to debug further.
perf: add perf-dwarf featureAnuj MittalNEWenhancementMediumFuture5
 15       

Cal Bugs

IDSummary (8 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
9525*
9525 Duplicate of 9525.
Make install prompt available on all consolesCalifornia SullivanACCEPTEDenhancementMedium2.994
11807*
11807 The kernel lets you build firmware into it via the CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR variables. We should have some way to set and use these variables in a kernel recipe.
kernel tooling should support building in firmwareCalifornia SullivanNEWenhancementMedium2.993.5
12170*
12170

(In reply to comment #0) > The objective of this bug is to examine the viability to add ext2 support to > poky tiny images.

Just to clarify, this bug is to add support for creating/modifying ext partitions on poky-tiny, this will be added via busybox.

While doing this I will also check what other functionality should or may be added to poky-tiny.
Add mkfs.ext support to busybox on poky-tinyCalifornia SullivanIN PROGRESS REVIEWenhancementMedium2.993
11291*
11291

Agreed that we need to break the bug down more as this is a metabug.

Action taken to file the other bugs!
Don't generate live images for x86California SullivanNEWenhancementMedium+2.991
11816*
11816 Thought Stephano was going bump this to 2.6 for me. Doing it now.
secure boot implementation using systemd-boot bootloaderCalifornia SullivanNEWenhancementMedium+2.994
12584*
12584

Currently, the generic EFI boot method using the following assume root=/dev/sda2 or similar:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks/efi-bootdisk.wks.in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd-bootconf_1.00.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/grub/grub-bootconf_1.00.bb

Using /dev/sda and such is not a reliable way to boot, as it depends on the install media enumerating to a certain value. Instead random UUIDs should be used.

This will require both the -bootconf recipes and wic to know the same random value. This value also needs to be saved in sstate, else issues will arise when rebuilding and doing package upgrades.

The current path to explore to accomplish this is as follows: 1) modify wic to take a file containing a UUID as input for its UUID creation 2) merge the -bootconf recipes into one recipe with multiple packages. This package would also deploy the UUID file for consumption. 3) modify efi-bootdisk.wks.in to use the new wic functionality and UUID file.

This would allow all bootloaders and wic to know the same UUID, and since it uses deploy should work with sstate. The new bootconf recipe would need to be extensible to support any arbitrary bootloader as well.
Generic EFI booting needs to support random UUIDsCalifornia SullivanNEWnormalMedium+2.99
8773*
8773

The differences between the two BSP sets are mostly logical right now:

common-pc is a base configuration + virtio configurations + some AMD configurations.

intel-common is common-pc without virtio or AMD configurations, but with many Intel drivers enabled, and with expanded module support.

There are some changes I would like to make, but it would be mostly cosmetic, so I am lowering the priority on this for now.
refactor yocto-kernel-cache common-pc / intel-common scc/cfg file to reduce delta & overlapCalifornia SullivanACCEPTEDenhancementMediumFuture11
 7       

Juro Bugs

IDSummary (15 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12639(reproducibility) nspr packages contain timestampsJuro BystrickyNEWnormalMedium2.6reproducibility
12638*(reproducibility) pulseaudio packages contain build host referencesJuro BystrickyIN PROGRESS IMPLEMENTATIONnormalMedium+2.6 M1reproducibility
12543*
12543

Part of the problem (build host references) fixed here: https://patchwork.openembedded.org/patch/147228/

timestamps fix proposed here:

https://patchwork.openembedded.org/patch/149947/
(reproducibility) python-xcbgen contains host references and timestampsJuro BystrickyIN PROGRESS REVIEWnormalLow2.99reproducibility
6630*
6630 Please update this milestone. If it is not going into 2.5 push to 2.99.
linux-yocto: kernel-dev package does not include target arch scripts binariesJuro BystrickyIN PROGRESS DESIGN COMPLETEenhancementMedium2.993
4389*
4389

(In reply to comment #30) > (In reply to comment #29) > > Just to keep you posted, I attached a new patch, (combining your work with > > mine). > > I tested it with > > > > $ core-image-sato-sdk -ctestimage > >

> On my side, this isn't the first time I've heard of qemuppc getting sigill > and crashing. > > I personally wouldn't want to hold up the work you are doing on ppc, so is > it possible to do an arch test, and require the on-target "make scripts" for > PPC ? >

I actually managed to build the package for powerpc as well meanwhile.

I had to create the images with static linking though (passing -static to CC). So the binaries a bit bigger as a consequence. I'll try to investigate a bit deeper later on.
kernel: Remove "make scripts" requirement for module building from SDK/on targetJuro BystrickyIN PROGRESS DESIGN COMPLETEenhancementMedium+2.995
10646*
10646 Please provide an update on the status of this and let me know if it will be ready for YP 2.5 M3.
Add support for Altera/Nios2 in qemuJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.995
12421Support reproducible build for (Debian) packages built for core-image-minimalJuro BystrickyIN PROGRESS REVIEWenhancementMedium+2.99
5695*
5695

Looking at the log file, looks like several tests fail due to a know issue related to the default encoding used in Yocto-build images ('utf-8') being different from the assumed 'ascii' by the tests (see bug 10522). This will no longer be the case after 2.5 M1 milestone, when manifest patches that remove the mentioned default encoding are scheduled to be implemented.

Among others, the following are in this case (UnicodeEncodeError not raised):

test_hasattr test_0_args_with_overridden___str__ test_1_arg test_1_arg_with_overridden___str__ test_many_args_with_overridden___str__ test_unicode test_output_htmlcalendar test_with_marshal

that said, it would be worth testing with the default encoding set to 'ascii' to verify this.
python: ptest cases failedJuro BystrickyNEWnormalLowFuture
8097*Build Appliance: Missing splash screenJuro BystrickyNEWnormalLowFuture2
8583*
8583 Meant to say hard-coded paths (not links).
strace shows accesses in non-existent location.Juro BystrickyIN PROGRESS DESIGNminorLowFuture 2
3999*
3999

Darren,

Ok - thanks. So when the bug is resolved the yocto-kernel script will provide new information to the user.

Thanks
provide description and compatibility data with kern-features.rcJuro BystrickyIN PROGRESS DESIGNenhancementMediumFuture2
5087*
5087 Reference documentation about timekeeping in vmWare VMs.
Sometimes building under BA can fail due to make utility reporting timestamps anomaliesJuro BystrickyNEWnormalMediumFuture5
5421*
5421 Once multiconfig interdependencies work, this should be implementable.
Support multiple MACHINE installs per SDKJuro BystrickyNEWenhancementMediumFuture
9885*
9885

I'm afraid this is not possible, or at least it is not trivial. There are dozens of header files that are needed. As we cannot distribute the extracted files, the onus of extraction is put up the user. meta-darwin layer README contains the instructions on how to do this. However, it is possible there is an alternative out there somewhere in the open source community (similar to mingw, which provide their own set of header files

in order not to infringe on MS copyright). I am not aware of anything like that, though.
[meta-darwin] remove dependency on Mac OS SDK components which aren't distributableJuro BystrickyNEWenhancementMediumFuture
11348*Create demo showing Yocto built FPGA image in actionJuro BystrickyNEWenhancementMediumFuture5
 15       

Stephano Bugs

IDSummary (5 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
12666*
12666 Please try this on a NUC to check.
[2.5 M3 RC1] BSP-QEMU:core-image-sato-sdk-genericx86-64.hddimg unable to connect to console with serial on Minnowboard TurbotStephano CetolaNEWnormalMedium+2.6 M1
12561*
12561

This should cover when customers should use which Linux (linux-intel vs linux-yocto), which versions of meta-intel go with which versions of poky, and what versions have been QA'd. It could also show current QA status.

It should be fashioned after the freescale community bsp.

We should also clean up information like this:

https://wiki.yoctoproject.org/wiki/Meta-intel_Release_Process
Create a community resource for meta-intelStephano CetolaACCEPTEDnormalMedium+2.99
5841*
5841 I suspect this has something to do with the VERB table provided by firmware as the driver reads that for configuration data. Some additional investigation is warranted though. Marking as low priority as the audio does play.
Minnow: hda-intel: Invalid position bufferStephano CetolaNEWnormalLowFuture
11532*
11532

Parse CONFIG file and store RMC.efi log to file if

LOG=/path/to/log is found.
RMC: [EFI] Add log optionStephano CetolaNEWenhancementMediumFuture2
11533*
11533 Parse CONFIG file and enable verbosity if DEBUG=1 is found.
RMC: [EFI] Add debug optionStephano CetolaNEWenhancementMediumFuture2
 5       

Bruce Bugs

IDSummary (19 tasks) AssigneeStatusSeverityPMilestoneWhiteboardE
6986*
6986 I'm holding onto this one.
linux-yocto do_patch fails with a long working directory pathBruce AshfieldIN PROGRESS DESIGNnormalMedium2.62
8191*
8191

(In reply to comment #26) > is this change still applicable to master and can we get it submitted? if > not, can we close as wontfix. > > I won the lottery an got the AR from the bug triage meeting : )

Ha!

The answer is somewhere in the middle of the options:

- the patch is absolutely still valid for master, I build with this for everything I do
- I've missed the cutoff for the release, but will immediately submit it for the next cycle
- With CVEs, kernel-devsrc and this bug having some lively discussion about what is possible, the time to bike-shed this on the oe-core mailing list never came about.
I'll update the target for this, do some tweaks and attach a new variant.
apply kernel config fragments to arbitrary kernelsBruce AshfieldIN PROGRESS IMPLEMENTATIONenhancementHigh2.992
6022*
6022

Moving to 2.1, since this is impacted by the split of the meta data out of the kernel tree. We need that to settle, and then can much more easily to this. But squeezing it all into the same

release is a stretch.
kernel-dev: How do I know which features are available for KERNEL_FEATURES ?Bruce AshfieldIN PROGRESS DESIGN COMPLETEenhancementMedium2.992
7646*
7646 Moving to M3.
KBUILD_DEFCONFIG does not work if config file is created as a result of patch to be appliedBruce AshfieldIN PROGRESS IMPLEMENTATIONenhancementMedium2.993
8743*
8743 This will change with the enablement of fragments for more kernel variants. So moving to 2.5, but it may be fixed with 2.4 (and I'll update accordingly then).
configme --allnoconfig breaks defconfig generated with kconfig / make savedefconfigBruce AshfieldIN PROGRESS IMPLEMENTATIONnormalMedium2.993
9069*
9069 I won't have cycles for this. If someone else grabs it, I won't complain.
perf: missing python modules for scripts in 'perf report'Bruce AshfieldIN PROGRESS REVIEWnormalMedium2.994
9656*NFS boot failed due No working init found kernel panic on qemuBruce AshfieldACCEPTEDnormalMedium2.992
10962*
10962

Marking this as accepted, and putting 4 days in as an estimate.

I also put m3 as the milestone, but it will more than likely get pushed out of the 2.3 release unless someone grabs this from me.
device tree compiler does not support @ to compile overlayBruce AshfieldACCEPTEDnormalMedium2.994
12283*
12283

Building a fitImage that include an initramfs force the kernel to depends on rootfs. This in turn cause rebuilding anything on any change.

For example, if the image is not included, building an out-of-tree kernel module require pretty much just building the kernel + the module. Yet, when you enable fitImage, building the same out-of-tree kernel module force re-building all the user space application as well.

Also, the image creation, fit or wic should not be kernel specific. The code found in kernel-fitimage.bbclass create an ITS file and then call uboot-mkimage. There is nothing there that is kernel specific.

This code should be done within the image recipe, once the kernel uImage and the rootfs has been built, as is other image type.

Now I understand that if INITRAMFS_IMAGE_BUNDLE is set to 1 that the kernel need to be involved, but when INITRAMFS_IMAGE_BUNDLE is set to 0, there are no valid reason to have the kernel create the image itself instead of the image recipe creating the image and removing that kernel/rootfs dependency.
Building a fitImage including INITRAMFS_IMAGE (wo/ BUNDLE) cause the kernel to depend on rootfs which is badBruce AshfieldACCEPTEDnormalMedium2.993
12482*
12482

Perf can be optionally build with many features:

Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ OFF ] ... libaudit: [ OFF ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ OFF ] ... numa_num_possible_cpus: [ OFF ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ OFF ] ... bpf: [ on ]


The perf recipe has partial PACKAGECONFIG feature support.

Investigate and if needed add support for libaudit, *numa*, get_cpuid.
perf: Add PACKAGECONFIGs for auto-detected features such as libauditBruce AshfieldACCEPTEDenhancementMedium2.993
12535*kernel-devsrc do_package takes unreasonably long timeBruce AshfieldIN PROGRESS REVIEWnormalMedium2.99
12290*
12290

Given current events on the mailing list ('kernel: Add support for multiple kernel packages'), I am postponing doing anything here for now, as this touches similar places.

I have a slightly better understanding of the issues now, tough. And it's slightly different than described originally in comment #0.

One of my recipes is kernel-module-mac80211.bb, which builds more than one kernel module, each for different hardware. Let's call one of those modules ralink.ko.

One important thing I didn't mention before is that I have KERNEL_MODULES_META_PACKAGE = "". I need this, because the recipe name corresponds to a helper kernel module created during the build, and there is no main kernel module as such which could serve as the recipe name.


Firstly, I need to add extra RDEPENDS to some of the automatically splitted packages. This stopped working, as my RDEPENDS_${PN} = "crda" has no effect anymore. RDEPENDS_${PN}${KERNEL_MODULE_PACKAGE_SUFFIX} = "crda" would work, if it didn't cause checksum hash mismatch errors.


Secondly, because of KERNEL_MODULES_META_PACKAGE="" I get an empty package with the name of the recipe with no additional dependencies, kernel-module-mac80211. Previously, that package contained mac80211.ko, but now mac80211.ko is moved to the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package. So during image creation the empty package is installed.

Given the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package does RPROVIDE kernel-module-mac80211, the issue is creation of the kernel-module-mac80211 package due to ALLOW_EMPTY_${PN} in module.bbclass.


I think I have an idea for how to solve these.
cross recipe kernel module dependency generation stopped workingBruce AshfieldACCEPTEDnormalMedium+2.99Backport 2.3.4, 2.4.3, 2.5.1...2
12563*
12563

I noticed that the do_kernel_configcheck task of linux-yocto produces some great auditing reports for the kernel config, but mine was reporting several invalid CONFIG_ options. These were all from the net/netfilter/ipvs/Kconfig file.

This file uses a mix of tabs and spaces between the "config" and the name of the config option. This confuses kconf_check. Or, more precisely, the regex on line 244, "^[ ]*\(menu\)*config ". The space at the end of the regex is the problem.

This should be changed to, "^[ ]*\(menu\)*config[ ]", in order to handle the net/netfilter/ipvs/Kconfig file.
kconf_check - doesn't pickup all available CONFIG_ optionsBruce AshfieldIN PROGRESS IMPLEMENTATIONminorMedium+2.991
12576*
12576 I'm using rocko branch
Error building custom 4.14 kernel caused by do_shared_workdirBruce AshfieldIN PROGRESS IMPLEMENTATIONnormalMedium+2.992
1924*
1924 Waiting For Upstream status is being removed, changing to Accepted.
[LTP] 'vma01' case failed on non-x86 platforms with Yocto 1.2 M2 rc1Bruce AshfieldACCEPTEDnormalMediumFuture
2267*
2267 bumping to 1.9, since this can't make the feature freeze for 1.8.
Integrate DISTRO_FEATURES with KERNEL_FEATURESBruce AshfieldIN PROGRESS DESIGN COMPLETEenhancementMediumFuture25
5305*
5305

The use case was a developer asking on #yocto how to extend a kernel with a custom driver and export it's UAPI.

I could not tell from the current situation or documentation how to perform this cleanly.

Consider this a duplicate of 5305.
Make sanitized kernel headers availableBruce AshfieldIN PROGRESS IMPLEMENTATIONenhancementMediumFuture 3
9480*
9480

It doesn't work currently:

MACHINE = "qemuarm64" DEFAULTTUNE = "aarch64_be"

$ bitbake linux-yocto


aarch64_be-poky-linux-ld.bfd: usr/initramfs_data.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file usr/initramfs_data.o make[3]: *** [usr/built-in.o] Error 1

 CC      kernel/exec_domain.o

make[2]: *** [usr] Error 2 make[2]: *** Waiting for unfinished jobs....

 OBJCOPY arch/arm64/kernel/vdso/vdso.so
 VDSOSYM arch/arm64/kernel/vdso/vdso-offsets.h
 CC      security/keys/keyring.o
 CC      kernel/panic.o
 CC      kernel/cpu.o
 AS      arch/arm64/kernel/vdso/vdso.o
 CC      kernel/exit.o
 CC      kernel/softirq.o
 LD      security/integrity/integrity.o
 CC      kernel/resource.o

aarch64_be-poky-linux-ld.bfd: security/integrity/iint.o: compiled for a little endian system and target is big endian CC fs/open.o

aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file security/integrity/iint.o make[4]: *** [security/integrity/integrity.o] Error 1 make[3]: *** [security/integrity] Error 2 make[3]: *** Waiting for unfinished jobs....

[snip]

 LD      arch/arm64/mm/built-in.o

aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/dma-mapping.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/dma-mapping.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/extable.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/extable.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/fault.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/fault.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/init.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/init.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/cache.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/cache.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/copypage.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/copypage.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/flush.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/flush.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/ioremap.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/ioremap.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmap.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/mmap.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pgd.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/pgd.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/mmu.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/mmu.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/context.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/context.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/proc.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/proc.o aarch64_be-poky-linux-ld.bfd: arch/arm64/mm/pageattr.o: compiled for a little endian system and target is big endian aarch64_be-poky-linux-ld.bfd: failed to merge target specific data of file arch/arm64/mm/pageattr.o make[3]: *** [arch/arm64/mm/built-in.o] Error 1 make[2]: *** [arch/arm64/mm] Error 2

 CC      fs/exec.o
[snip]
linux-yocto: make it work with arm big endianBruce AshfieldACCEPTEDenhancementMediumFuture 7
 18       
Personal tools