尝试使用“thud”版本构建 yocto 映像，构建 thud分支bitbake附带的 u-boot 版本失败meta-gumstix，这是2016.03（看起来很古老？）。
我看到的错误是关于冲突的类型，例如
ERROR: u-boot-v2016.03+gitAUTOINC+df61a74e68-r0 do_compile: oe_runmake failed
…
/home/kwisatz/yocto-new/build/tmp/work/overo-poky-linux-gnueabi/u-boot/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/usr/include/libfdt_env.h:71:30: error: conflicting types for 'fdt64_t'
typedef uint64_t FDT_BITWISE fdt64_t;
在 Internet 上搜索，很快就会遇到一系列线程，这些线程解释说问题出在包libfdt-dev.h附带的标题上。dtc有些人建议将dtc软件包列入黑名单或卸载，但据我所知，yocto 的 gumstix 层中的 u-boot 配方明确要求它：
DEPENDS += "dtc-native"
另请参阅https://patchwork.openembedded.org/patch/147816/ 但是，在上面链接的线程中，我们谈论的是 2018.01 和 2018.03 版本，而不是 2016.03
thud 的 poky 层带来了 u-boot 2018.07，它构建得很好，但是有了那个，我的 overo (Airstorm-Y) 将不再启动：
Booting from nand with DTS...
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=4", size 1013 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 8108, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1485359018
UBI: available PEBs: 0, total reserved PEBs: 8108, PEBs reserved for bad PEB handling: 160
** File not found /boot/omap3-overo-storm-tobi.dtb **
Loading file '/boot/zImage' to addr 0x82000000 with size 5097744 (0x004dc910)...
Done
Kernel image @ 0x82000000 [ 0x000000 - 0x4dc910 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
我不完全确定这个引导问题是否与 u-boot 构建或我构建的内核映像有关（请参阅我以前的线程）？
关于如何解决这个问题的任何提示？是否有更新版本的 u-boot 在 yocto 的 gumstix 层中，我还没有发现，或者你有任何其他提示我可以为我的 overo 获得一个工作的 yocto 图像吗？
PS 请注意，在构建过程中，我也看到了这些警告，但我认为这里没有实际问题：
WARNING: u-boot-v2016.03+gitAUTOINC+df61a74e68-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0006-duovero-Read-eeprom-over-i2c.patch
patching file board/gumstix/duovero/duovero.c
patching file include/configs/duovero.h
Hunk #2 succeeded at 50 with fuzz 2 (offset -4 lines).
Now at patch 0006-duovero-Read-eeprom-over-i2c.patch
[…]