-
Notifications
You must be signed in to change notification settings - Fork 1
/
notes
1739 lines (1239 loc) · 62.2 KB
/
notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
vim: expandtab ts=4 sts=4 sw=4 textwidth=78 colorcolumn=78
Index:
61. add/use a custom LICENSE
60. static MAC address
59. GPLv3 tooling, but not in image
58. python3
57. xz OOM
56. Adding FORTRAN support
55. Turn off PNBLACKLIST
54. LICENSE_FLAGS_WHITELIST
53. x86 ilp32 build
52. bbappend for target only
51. Adding something to eSDK
50. Forcing a stuck variable (set in BSP, etc)
49. Removing busybox
48. Use local time for timestamps
47. How to ask for a given version
46. How to make a recipe MACHINE-specific
45. Multilib build (mix 64- and 32-bit)
44. Build for selected architectures only
43. Switch to systemd
42. Adding kernel modules
41. Inter-task/recipe locks (e.g. restricting the number of fetches)
40. Pretty buildstats charts
39. Add a full python to the SDK
38. Adding (and using) the linaro toolchain
37. Scheduling inter-recipe tasks
36. Post-process
35. Tasks
34. Bad shared libraries
33. Building/using an initramfs
32. Debugging app on target with gdb on dev host
31. Working with sstate stamps
30. Autotools build where $B != $S
29. Invoking the host's compiler while cross-compiling
28. Disabling parallel build
27. Using the package feed from a build machine on a target device
27.a ipk/opkg
26. devshell environment
25. Faulty host tools (buildtools-tarball)
24. Removing a package
23. bmaptool
22. Cleaning up
21. Investigating variables
20. menuconfig
19. SDK
19.a ADT
19.b populate_sdk
19.c meta-toolchain
19.d native development
19.e manual Makefile
18. Image package list
17. Notes for imx53qsb
16. Notes on setting up an ssh server in an image
15. Setting the size of an image
14. Ignoring .bbappends with no .bb
13. Ignoring certain configuration items
12. To obtain a list of supported output image types
11. Recipe dependency information
10. How to restart the build when a recipe fails
9. How to modify the autotool ./configure options
8. How to add packages to an image
7. How to build an image with an -rt kernel
6. - removed -
5. Quick start instructions
4. How can I just grab all the necessary files from the net?
3. What images are available from which to choose?
2. General task list
1. How to obtain the list of tasks
==============================================================================
61. add/use a custom LICENSE
If a recipe in a layer needs a custom license, create the directory:
${LAYERDIR}/additional-licenses
In that directory create a file whose name is the license name (to be
put in LICENSE = "<license name>") and whose contents is the text of the
license itself.
Then, in that layer's conf/layer.conf add:
LICENSE_PATH:append = " ${LAYERDIR}/additional-licenses"
Now, in the recipe(s) in that layer you can do:
LICENSE = "<new license name>"
==============================================================================
60. static MAC address
A lot of embedded boards don't come with static MAC addressess assigned
from the manufacturer and stored in EEPROM. Therefore each time the board
boots up, it gets a quasi-randomly generated MAC address. This makes it
difficult to use DHCP to assign IP addresses to board if their MAC
addresses aren't static.
The method to fix this depends on the init system in use.
sysvinit: modify /etc/network/interfaces
.
└── recipes-core
└── init-ifupdown
├── files
│ └── imx233-olinuxino-maxi
│ └── interfaces
└── init-ifupdown_%.bbappend
recipes-core/init-ifupdown/init-ifupdown_%.bbappend:
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
recipes-core/init-ifupdown/files/<machine>/interfaces:
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
hwaddress ether e6:73:76:69:51:42
systemd: create /etc/systemd/network/*.network file
.
└── recipes-core
└── systemd
├── files
│ └── rock-pi-e
│ └── 50-eth1.network
└── systemd_%.bbappend
NOTE: the "50-" part of "50-eth1.network" is necessary!
NOTE: the ".network" part of "50-eth1.network" is necessary!
recipes-core/systemd/systemd_%.bbappend:
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI:append:rock-pi-e = " file://50-eth1.network"
do_install:append:rock-pi-e() {
install -d ${D}${sysconfdir}/systemd/network
install -m0644 ${WORKDIR}/50-eth1.network ${D}${sysconfdir}/systemd/network/
}
recipes-core/systemd/files/<machine>/50-eth1.network:
[Match]
Type=ether
Name=eth1
[Link]
MACAddress=e6:73:76:69:51:43
[Network]
DHCP=yes
[DHCP]
UseMTU=yes
RouteMetric=10
ClientIdentifier=mac
NOTE: In the same way that IPv4 addresses have private ranges (e.g.
192.168.x.y/24 and 10.x.y.z/8) so too do MAC address have private
ranges (or "locally administered address ranges" - LAAR). A LAAR is
determined by the second least significant bit of the most
significant byte of the MAC address. If it is 0 then the MAC address
is universal, otherwise it's a LAAR. Unicast LAAR addresses have
one of the following 4 patterns:
_2:__:__:__:__:__
_6:__:__:__:__:__
_a:__:__:__:__:__
_e:__:__:__:__:__
==============================================================================
59. GPLv3 tooling, but not in image
<mcfrisk> bps: you can enable build of some GPLv3 recipes, e.g. tooling
but mask their binary packages out from images. E.g. in distro config:
WHITELIST_GPL-3.0 += "binutils" and PACKAGE_EXCLUDE += "binutils-dbg
binutils-staticdev binutils-dev binutils-doc binutils-locale libbfd
binutils"
<mcfrisk> bps: one more example from my distro config:
INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+",
WHITELIST_GPL-3.0 += "gdb", PACKAGE_EXCLUDE += "gdbserver gdb-dbg
gdb-staticdev gdb-dev gdb-doc gdb-locale gdb"
==============================================================================
58. python3
the configuration error:
| configure: error: python3-config not found…
is fixed by:
inherit python3native
the compile error:
| fatal error: Python.h: No such file or directory
| #include <Python.h>
| ^^^^^^^^^^
is fixed by:
DEPENDS += "python3"
==============================================================================
57. xz OOM
If a build fails due to OOM killing an xz process, try tweaking
XZ_MEMLIMIT
or
XZ_DEFAULTS = "--memlimit=10% --threads=8"
==============================================================================
56. Adding FORTRAN support
FORTRAN support is not enabled/built in gcc by default. To enable it add
the following to conf/local.conf:
FORTRAN = ",fortran"
==============================================================================
55. Turn off PNBLACKLIST
$ bitbake mpv
ERROR: Nothing PROVIDES 'mpv'
mpv was skipped: Recipe is blacklisted: Needs forward porting to use python3
create an append in workspace
$ devtool create-workspace
vi workspace/appends/mpv_%.bbappend
PNBLACKLIST[mpv] = ""
there are references saying that simply adding
PNBLACKLIST[mpv] = ""
to conf/local.conf will work on its own, but I haven't been able to see
that happen. The only thing that I find working is the bbappend.
==============================================================================
54. LICENSE_FLAGS_WHITELIST
$ bitbake mpv
ERROR: Nothing PROVIDES 'mpv'
mpv was skipped: because it has a restricted license 'commercial'. Which is not whitelisted in LICENSE_FLAGS_WHITELIST
conf/local.conf:
LICENSE_FLAGS_WHITELIST = "commercial"
==============================================================================
53. x86 ilp32 build
use MACHINE="qemux86-64" and set DEFAULTTUNE="core2-64-x32"
==============================================================================
52. bbappend for target only
By default, a .bbappend file will patch both the native and target
versions of the build. How do I modify it so that it only affects the
target build and not the native build?
SRC_URI_append_class-target = "file://..."
==============================================================================
51. Adding something to eSDK
SDK_TARGETS += "cmake-native:do_populate_sysroot \
python3-native:do_populate_sysroot"
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=10600
==============================================================================
50. Forcing a stuck variable (set in BSP, etc)
Sometimes a layer will set a variable by using an equal sign, meaning that
it is now stuck at whatever value that layer set it to. Normally this
variable would now not be able to be adjusted in conf/local.conf. However
there is an overriding syntax to unstick such variables:
PREFERRED_VERSION_linux-riscv_forcevariable = "4.15%"
==============================================================================
49. Removing busybox
Example from someone's distro config, but maybe it works in local.conf
too?
VIRTUAL-RUNTIME_base-utils = ""
ALTERNATIVE_PRIORITY_pn-busybox = "1"
The priority setting makes bitbake pull in alternatives from util-linux /
coreutils when appropriate.
==============================================================================
48. Use local time for timestamps
In local.conf:
BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"
==============================================================================
47. How to ask for a given version
PREFERRED_VERSION_<package-name> = "numbers%"
e.g.
PREFERRED_VERSION_tpm2-tss = "git%"
PREFERRED_VERSION_gzip-native = "1.8%"
==============================================================================
46. How to make a recipe MACHINE-specific
PACKAGE_ARCH = "${MACHINE_ARCH}"
==============================================================================
45. Multilib build (mix 64- and 32-bit)
If the overall build is 64-bit but you want to build one app 32-bit:
$ bitbake lib32-<your app>
==============================================================================
44. Build for selected architectures only
To enable specific architectures and disallow all others:
COMPATIBLE_MACHINE = "(-)"
COMPATIBLE_MACHINE_x86 = "(.*)"
COMPATIBLE_MACHINE_x86-64 = "(.*)"
COMPATIBLE_MACHINE_armv6 = "(.*)"
COMPATIBLE_MACHINE_armv7a = "(.*)"
In this case we allow x86, x86-64, armv6, and armv7, but disallow all
others.
To allow all architectures but turn off specific ones (a sort of
"INCOMPATIBLE_MACHINE", if you will...):
COMPATIBLE_MACHINE_armv4 = "(!.*armv4).*"
COMPATIBLE_MACHINE_armv5 = "(!.*armv5).*"
COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
Here armv4, armv5, and mips64 are not allowed, but by default anything
else is.
==============================================================================
43. Switch to systemd
Add the following the local.conf:
(prior to 3.0-zeus)
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
3.0-zeus and later:
INIT_MANAGER = "systemd"
other potential settings for INIT_MANAGER include:
none
sysvinit
systemd
mdev-busybox
==============================================================================
42. Adding kernel modules
By default no kernel modules are included in an image, which allows you to
choose which ones (individually) to package. If you want to add all the
default modules to an image:
MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
to machine.conf (or local.conf?). To select modules individually use:
IMAGE_INSTALL += "kernel-module-<name>"
==============================================================================
41. Inter-task/recipe locks (e.g. restricting the number of fetches)
Apparently it's possible to set a lock such that any task that uses the
same lock will have to wait for it to be available(!). This allows a user,
for example, to setup a lock for all fetch tasks so that they no longer
occur in parallel:
do_fetch[lockfiles] += "${TMPDIR}/myfetch.lock"
The name isn't critical, it just needs to be the same in all of the
recipes you wish to have participate in this exclusive fetching.
https://lists.yoctoproject.org/pipermail/yocto/2015-July/025418.html
==============================================================================
40. Pretty buildstats charts
A while back (2011) Richard Purdie added the functionality to display
detailed, graphical profiles of a build, heavily borrowed from the Linux
kernel's "pybootchartgui" functionality.
To get your build to generate the needed data, make sure "buildstats" is
included in USER_CLASSES.
Once your build completes, run:
$ path/to/meta-poky/scripts/pybootchartgui/pybootchartgui.py $TMPDIR/buildstats/<image>-<$MACHINE>
e.g.
$ ~/devel/yocto/releases/master/layers/meta-poky/scripts/pybootchartgui/pybootchartgui.py tmp/buildstats/core-image-full-cmdline-beaglebone
Some suggested cmdline options to pybootchartgui.py are:
$ <command> <image arg> \
-f svg \
-s 5 \
-o /tmp
-f <FORMAT> specify a FORMAT, one of svg, pdf, png (default)
-s <NUM> split the output into <NUM> files
-o <DIR> place the output into file(s) at <DIR>
==============================================================================
39. Add a full python to the SDK
The python that gets added to the SDK is rather minimal, to add a "full"
python to your "-c populate_sdk" add the following to your config:
TOOLCHAIN_HOST_TASK_append = " nativesdk-python-modules"
see: https://lists.yoctoproject.org/pipermail/yocto/2015-April/024446.html
==============================================================================
38. Adding (and using) the linaro toolchain
When working with ARM device (specifically CortexA) the base OE layers
contain the necessary bits to create a working cross-compiler. But since
Linaro specializes in ARM and ARM toolchains you might find the Linaro GCC
toolchain is: more up to date, has better SoC support, has more fixes, has
more testing, ...
To use the linaro toolchain is quite simple:
- add the linaro layer to your bblayers
- tell bitbake to prefer it to the base toolchain
$ bitbake-layers add <path to meta-linaro/meta-linaro-toolchain>
Then edit conf/local.conf and add:
GCCVERSION = "linaro-4.9%"
SDKGCCVERSION = "linaro-4.9%"
==============================================================================
37. Scheduling inter-recipe tasks
https://www.mail-archive.com/[email protected]/msg41478.html
Q. Is it possible to mark two or more tasks to run exclusive?
IOW, is it possible to schedule a task in one recipe relative to a task
in another recipe?
A. e.g.
do_fetch[depends] += "xxx:do_fetch"
Put this in the bb/bbappend of one recipe, "xxx" is the other recipe.
==============================================================================
36. Post-process
To do post-processing tweaks to an image before it gets packaged up into
an image, see:
IMAGE_POSTPROCESS_COMMAND
e.g. remove /etc/version from image:
remove_etc_version() {
rm ${IMAGE_ROOTFS}${sysconfdir}/version
}
ROOTFS_POSTPROCESS_COMMAND += "remove_etc_version ; "
==============================================================================
35. Tasks
In base.bbclass we have the following fundamental tasks:
do_fetch
do_unpack
do_configure
do_compile
do_install
do_package
A task can be completely replaced (class and/or recipe):
do_install () {
oe_runmake 'DESTDIR=${D}' install
}
You can also add to a task (before or after) by using "_prepend" or
"_append":
do_install_append () {
...
}
do_configure_prepend () {
...
}
There are 3 ways a task can be removed:
1) NULLing out the contents:
do_configure () {
:
}
2) using "noexec":
do_fetch[noexec] = "1"
3) using "deltask":
deltask configure
==============================================================================
34. Bad shared libraries
Some packages mistakenly create shared libraries that end with "*.so"
instead of "*.so.<maj><min>". In this case the default classes will scoop
up these "*.so" files and put them in the -dev package. To avoid this:
FILES_SOLIBSDEV = ""
FILES_${PN} += "${libdir}/*"
Here are some older incantations:
FILES_${PN} += "${libdir}/*.so"
FILES_SOLIBSDEV = ""
INSANE_SKIP_${PN} += "dev-so"
- or -
FILES+SOLIBSDEV = ""
SOLIBS = ".so"
INSANE_SKIP_${PN} += "dev-so"
==============================================================================
33. Building/using an initramfs
OE has:
COMPATIBLE_HOST = "(i.86|x86_64).*-linux
as part of core-image-minimal-initramfs so it will only work if the target
is x86-based. However, initramfs'es can still be used for other
architectures. Simply add "cpio" to IMAGE_FSTYPES and use the resulting
cpio archive as the initrd. The above only means this specific image
(core-image-minimal-initramfs) was meant only to run on x86-based targets,
not that other targets can't have initramfs'es.
Khem also points out you can make any image become an initramfs image by
adding:
INITRAMFS_IMAGE = "your-initramfs-image"
INITRAMFS_IMAGE_BUNDLE = "1"
Adam initially ended up with an initramfs cpio image of 69MB in size!
However he then noticed he had some unnecessary DISTRO_FEATURES enabled;
once they were disabled the image shrunk to 2.5MB.
==============================================================================
32. Debugging app on target with gdb on dev host
(email on oedev mailing list, info from Mats Karrman)
"
Prerequisites:
- a network connection between your target and your development host (it's
possible to use a tty too).
- OE built SDK installed on your host.
- gdbserver package installed on your target.
- your binary (my-program) on target
- an unstripped version of your binary in the working directory on host.
The exact commands below will vary with the install path of your SDK
(/usr/local/oecore-x86_64 in my case) and target specifics (e.g. powerpc,
ppce300c3... in my case).
On target:
# gdbserver :2345 my-program
On host:
$ source /usr/local/oecore-x86_64/environment-setup-ppce300c3-oe-linux
$ powerpc-oe-linux-gdb my-program
(gdb) set sysroot /usr/local/oecore-x86_64/sysroots/ppce300c3-oe-linux
(gdb) target remote <target-ip>:2345
(gdb) br main
(gdb) cont
...
"
==============================================================================
31. Working with sstate stamps
Mike Looijmans asked a question on the mailing list about sstate.
Specifically he wants to share sstate across two (or more) build machines.
The second build on another machine, however, insists on rebuilding even
though it shouldn't. Richard Purdie provides tonnes of useful information:
"
Let me explain the manual process you can follow for this. Its a pain to
walk through and its what -S attempts to automate but you should be able
to get an answer manually this way.
You have BUILDA and BUILDB, the two builds which should be reusing
sstate but are not. The fact they're on different machines is irrelevant
to this procedure. It would help if these two builds are just the result
of "bitbake fpga-image-miami" but that isn't essential, it will just
introduce more noise. It will also help if they are either both built
from an existing sstate cache or both not.
The first thing I'd do in each build:
$ find tmp/stamps/ -type f | sort > stamplistA.txt
I'd then so something like:
$ meld stamplistA stamplistB
the next steps depend upon how clear the differences are. Basically
there should be some degree of commonality between the two builds and at
some point there will be divergence. We need to pinpoint the point of
divergence. The divergence will be in fpga-image-miami itself or in one
of its dependencies.
The one thing which can confuse this view is if some things were reused
from sstate. You can tell since a task which runs looks like:
tmp/stamps/i586-poky-linux/x11-common/0.1-r47.do_populate_sysroot.d90d4404368125acd109a2ac64ca688f.qemux86
and a task which is from sstate looks like:
tmp/stamps/all-poky-linux/gstreamer1.0-meta-base/1.0-r0.do_populate_sysroot_setscene.a49fa811727c557c14ab6ce6f2973587.qemux86
The "_setscene" part tells you this. Machine specific tasks have the
machine name appended to them ".qemux86" in this case. The hash
representing the task is clear in the filename
("a49fa811727c557c14ab6ce6f2973587" in this case").
You'll have to filter out any "noise" from these changes you're not
interested in. If a task is "_setscene" its dependencies may be missing
from the list of files entirely (no install/compile/configure etc.).
So you take a guess at the divergence point and take note of the two
different hashes. You can then find the corresponding siginfo files in
sstate:
$ find sstate-cache/ -name *d90d4404368125acd109a2ac64ca688f*
sstate-cache/d9/sstate:x11-common:i586-poky-linux:0.1:r47:i586:3:d90d4404368125acd109a2ac64ca688f_populate_sysroot.tgz
sstate-cache/d9/sstate:x11-common:i586-poky-linux:0.1:r47:i586:3:d90d4404368125acd109a2ac64ca688f_populate_sysroot.tgz.siginfo
which are the sstate files corresponding to my above x11-common task.
You will note that the first two letters of the hash are used as a
directory prefix. You can also find sigdata files in the stamp
directory:
$ find tmp/stamps/ -type f | grep d90d440
tmp/stamps/i586-poky-linux/x11-common/0.1-r47.do_populate_sysroot.d90d4404368125acd109a2ac64ca688f.qemux86
tmp/stamps/i586-poky-linux/x11-common/0.1-r47.do_populate_sysroot.sigdata.d90d4404368125acd109a2ac64ca688f
The sigdata and siginfo files are identical and equivalent. Once you
have the two sstate files, you can run:
$ bitbake-diffsigs A.siginfo B.siginfo
and this will tell you why their hashes are different. If you need help
deciphering that output, link to it and I can help.
If you didn't guess the divergence point correctly, it will tell you
that some prior task is actually different. In that case you would then
go and fetch the siginfo tasks for the previous task and compare those.
Either you find the difference or again, you have to trace it further
back.
"
Mike replies (in part) with:
"
So far, on one project (that is, NOT the fpga-image-miami) the
SRC_URI is slightly different. The machines are on various sides of
a router/firewall, so SRC_URI="git://${MY_SERVER}/blabla" evaluates
differently.
How can I tell the system that the value of "MY_SERVER" is irrelevant to
each and every build step in each and every recipe?
"
To which Richard replies:
"
The SRC_URI changing would indeed cause the tasks build separately since
bitbake thinks they're different things.
You have two ways of addressing this. Firstly, you could setup PREMIRROR
entries for these git urls which remaps them to the correct thing in
each case. There would then be one "canonical" url in the recipe and
you'd not need to change the hash generation.
The other way would be to either exclude the variable from the checksum
generation or give it a specific value. This would be something like:
do_fetch[vardepsexclude] += "SRC_URI"
you may also have to do this with other tasks that use SRC_URI such as
do_unpack and do_patch.
The other option is:
SRC_URI[vardepvalue] = "git://canonical/url/for/recipe"
which gives it a specific value to use for checksum purposes.
"
Chris Larson (in a completely unrelated thread) also points out:
"bitbake -S printdiff <target>" will tell you why the sstate wasn't
used (where <target> is: a specific recipe, your image, whatever). You
might need https://gist.github.com/kergoth/3713d779c14dc8b98f36
Martin Jansa says:
try "openembedded-core/scripts/sstate-diff-machines.sh" to see why
Also:
$ bitbake-whatchanged -v <your image>
==============================================================================
30. Autotools build where $B != $S
Replace
inherit autotools
with
inherit autotools-brokensep
==============================================================================
29. Invoking the host's compiler while cross-compiling
Search for/investigate: BUILD_CC
==============================================================================
28. Disabling parallel build
Sometimes a package builds perfectly fine using a parallel build (i.e. for
values of N in 'make -jN' greater than 1). But other times (usually due to
a badly constructed Makefile, such as when dependencies are not fully or
properly described) a build must be forced to build "serially" in order to
succeed.
In these cases, add the following to the recipe:
PARALLEL_MAKE = ""
==============================================================================
27. Using the package feed from a build machine on a target device
In order to use package management on your device, you need a way to serve
up the package set which is built on the build machine. Typically this is
done via HTTP. A simple and easy-to-use HTTP server is "lighttpd".
One of the key things to know is that, on the build machine, you must run:
$ bitbake package-index
after any change that might affect packaging or after any rebuild. NOTE
that the following invocation:
$ bitbake <some package> package-index
doesn't work since "package-index" must run at the very end, and the
dependencies aren't in place to enforce this. Therefore it is safest to
just simply invoke "bitbake package-index" by itself at the end of any
build.
27.a) ipk/opkg
Build Machine Setup
Regardless of which HTTP server you use, you'll need to figure out the
location from which it serves its files. This is usually described in
its configuration files as the "document root". Once you know this
location you'll probably want to create a symbolic link from your
$TMPDIR/deploy/ipk to the server's document root:
# ln -s ${PWD}/tmp/deploy/ipk /srv/www/htdocs/MYBOARD-files
In your target's configuration you'll also need to add "opkg" to its
image. For example, in conf/local.conf you could add:
CORE_IMAGE_EXTRA_INSTALL += "opkg"
NOTE that it is not necessary to add "package-management" to
EXTRA_IMAGE_FEATURES unless you want your board to start off with the
base package information that would be known at the end of the build.
If this is the case then you don't need to explicitly add "opkg" to
the image since this will be done by default by EXTRA_IMAGE_FEATURES.
As noted below (in the "Target Machine Usage" section), you'll need
to provide *.conf files on your target device in order to find
the package feeds. To make the process of creating the on-target
configuration files easier, meta-oe provides a recipe named
"distro-feed-configs" which you can include in your image which will
generate the /etc/opkg *.conf files and include them in your image.
In order to use this facility you'll need to do the following in your
conf/local.conf:
- add "distro-feed-configs" to your image:
CORE_IMAGE_EXTRA_INSTALL += "distro-feed-configs"
- provide a base url for fetching:
DISTRO_FEED_URI = "http://192.168.7.1/MYBOARD-files"
Target Machine Usage
On the target machine you need to have the "opkg" utility installed
(which is done during the build either by including
"package-management" in EXTRA_IMAGE_FEATURES or by adding the "opkg"
recipe to the image).
Next you need to have *.conf files in /etc/opkg which describe how and
from where to fetch the various package feeds. For example you might
create an "/etc/opkg/base-feeds.conf" file that looks like:
src/gz remote-all http://mymachine.com/MYBOARD-files/all
src/gz remote-armv7 http://mymachine.com/MYBOARD-files/armv7
src/gz remote-qemuarm http://mymachine.com/MYBOARD-files/qemuarm
However, if you included the "distro-feed-configs" package as part of
your image, these configuration files will already be included in your
image and you won't have to create this file yourself.
To refresh/update the ipk package management database on the target
simply run:
# opkg update
This will pull and update the database entries. Now you are ready to
install, remove, etc. any packages from the remote machine which is
serving up the packages.
==============================================================================
26. devshell environment
Trying to use the devshell feature had been giving me problems.
To start, my default prompt strings were making use of some functions that
I define in my ~/.bashrc; unfortunately these functions were not being
copied into the devshell environment so my prompts were causing errors to
be printed to the terminal.
Secondly, I had setup a number of environment variables in such a way
as to not expect any help from the "outside". For example my PATH
export didn't bother to include $PATH in its definition because I know
all the places I want my shell to look and don't need to add to an
existing definition. The same was true for a number of other (ironically)
build-related environment variables such as LD_LIBRARY_PATH, CPATH,
PKG_CONFIG_PATH... As you can guess, this doesn't play well with devshell
since the way it works is to set, for example, PATH and then load the
user's settings. Since my settings weren't incorporating any existing
PATH, all I'd get was whatever I had set in my ~/.bashrc.
To get around this problem I made use of the "custom" OE_TERMINAL type and
a specific bashrc file created specifically for devshell usage.
First, take your existing ~/.bashrc and copy it to ~/.bashrc.oe. Edit
~/.bashrc.oe and remove anything that relies on defined functions or that
sets a variable without incorporating its current definition.
Second, create a script somewhere on your PATH containing:
/bin/bash --rcfile /path/to/your/home/.bashrc.oe
and make it executable.
Finally in your conf/local.conf add the following lines:
OE_TERMINAL = "custom"
OE_TERMINAL_CUSTOMCMD = "/usr/bin/xterm -e /path/to/the/above/script"
==============================================================================
25. Faulty host tools (buildtools-tarball)
make-3.82 is known to have issues. The build system now contains a sanity
test to check not only your version of make, but can differentiate between
make's which have been patched by your distro to avoid the known issue(s).
If your distro fails this sanity test you can attempt to generate the
buildtools-tarball which you can then use exactly as you would an SDK.
$ bitbake buildtools-tarball
You'll then find the result in ${TMPDIR}/deploy/sdk
poky-eglibc-x86_64-i586-buildtools-nativesdk-standalone-1.4+snapshot-20130724.sh
Simply run this self-extracting shell script and choose an install
location:
$ ./poky-eglibc-x86_64-i586-buildtools-nativesdk-standalone-1.4+snapshot-20130724.sh
Enter target directory for SDK (default: /opt/poky/1.4+snapshot): <enter DEST dir here>
You are about to install the SDK to "<DEST>". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.
Just like when using an SDK, in the <DEST> directory you'll find an
environment file which you can "source" to begin using the tools from the
buildtools-tarball:
$ source <DEST>/environment-setup-x86_64-pokysdk-linux
If you don't trust your host system to correctly build the
buildtools-tarball, you can download a known working one from:
http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/buildtools/
==============================================================================
24. Removing a package
Use the BAD_RECOMMENDATIONS variable to list any packages that must be
filtered out during image creation. NOTE: BAD_RECOMMENDATIONS only works
for ipk.
==============================================================================
23. bmaptool
bmaptool[1] is a utility which speeds up the creation of sdcard images.
Without using bmaptools:
$ time dd if=core-image-minimal-imx53qsb.sdcard of=/dev/sdf
26034176+0 records in
26034176+0 records out
13329498112 bytes (13 GB) copied, 5340.82 s, 2.5 MB/s
real 89m0.826s
user 0m20.977s
sys 3m51.128s
Note that most of the above is just useless copying of blank/empty
sectors.
To use bmaptools two steps are required:
1) create the map
$ bmaptool create -o <bmapfile> <image>
2) use the map to create the sdcard
$ bmaptool copy --bmap <bmapfile> <image> <device>
$ time bmaptool create -o sdcard.bmap core-image-minimal-imx53qsb.sdcard
real 1m32.797s
user 0m33.658s
sys 0m6.001s
$ time bmaptool copy \
--bmap sdcard.bmap \