On Wed, Jul 29, 2020 at 02:20 PM, Brian Hutchinson wrote:
On Wed, Jul 29, 2020 at 02:07 PM, Brian Hutchinson wrote:
On Wed, Jul 29, 2020 at 4:49 PM Andrey Zhizhikin <
andrey.z@...> wrote:
>
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> [ 0.000000] Linux version 5.4.3+g66d6cfd8712d (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP PREEMPT Wed Feb 26 09:13:26 UTC 2020
This kernel version does not match to what is currently present in the
[dufell] branch of community BSP. Current linux-fslc-imx version
included there is actually 5.4.51. Version 5.4.3 looks a rather NXP
"default" kernel to me...
Can you provide a Yocto build header, where it is seeing which layers
are used in your build and at which revisions? This is what you
actually get at the beginning of bitbake execution.
Sure, here you go:
bitbake core-image-minimal
Loading cache: 100% |##################################################################################################| Time: 0:00:00
Loaded 3244 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "imx8mmevk"
DISTRO = "poky"
DISTRO_VERSION = "3.1.2"
TUNE_FEATURES = "aarch64 cortexa53 crc crypto"
TARGET_FPU = ""
meta
meta-poky = "HEAD:569b1f5d67c57de957e243997c53ec2f81dc8dfe"
meta-oe
meta-multimedia
meta-python = "HEAD:cc6fc6b1641ab23089c1e3bba11e0c6394f0867c"
meta-freescale = "HEAD:6bc3d8825c20d21528e24a7237ff7392e01a81bd"
meta-freescale-3rdparty = "HEAD:9000d8b388de98a13d6db2a98cd21602e0a7b715"
meta-freescale-distro = "HEAD:a1821b36af7bba4f6628e4244df7fc9a038d0f34"
WARNING: /home/hutch/yocto/imx8/imx8-fsl-community-bsp/sources/meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb:do_compile is tainted from a forced run
Initialising tasks: 100% |#############################################################################################| Time: 0:00:01
It could be that I didn't flash my sdcard right. I first tried the NXP release which generates a sdcard image. Both of the fsl-community-bsp builds I did generated a wic.gz image instead of a sdcard.bz2 image like NXP does.
I simply unzipped the wic.gz image and did a dd to my sdcard. Hopefully that's the right way to do it and I'm not still booting the original NXP image from my first try. That would be embarrassing ;)
Regards,
Brian
Here is the one from the fsl-community-bsp build using fslc-wayland distro and building core-image-base:
hutch@Gondor:~/yocto/imx8/fsl-community-bsp/build/tmp/deploy/images/imx8mmevk$ bitbake core-image-base
Loading cache: 100% |######################################################################################################| Time: 0:00:00
Loaded 3244 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-fslc-linux"
MACHINE = "imx8mmevk"
DISTRO = "fslc-wayland"
DISTRO_VERSION = "3.1"
TUNE_FEATURES = "aarch64 cortexa53 crc crypto"
TARGET_FPU = ""
meta
meta-poky = "HEAD:1bab588f4e0891032d57790661133ee153fa5f01"
meta-oe
meta-multimedia
meta-python = "HEAD:cc6fc6b1641ab23089c1e3bba11e0c6394f0867c"
meta-freescale = "HEAD:6bc3d8825c20d21528e24a7237ff7392e01a81bd"
meta-freescale-3rdparty = "HEAD:9000d8b388de98a13d6db2a98cd21602e0a7b715"
meta-freescale-distro = "HEAD:a1821b36af7bba4f6628e4244df7fc9a038d0f34"
Initialising tasks: 100% |#################################################################################################| Time: 0:00:01
Sstate summary: Wanted 0 Found 0 Missed 0 Current 1598 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 4104 tasks of which 4104 didn't need to be rerun and all succeeded.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 1 seconds
You're right. I see:
[ 1.337691] mmc0: CQHCI version 5.10
[ 1.341666] mmc1: CQHCI version 5.10
[ 1.345690] mmc2: CQHCI version 5.10
[ 1.381326] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA
... then
[ 1.554407] fsl-sai 30030000.sai: failed to get mclk0 clock: -2
[ 1.562823] mmc2: Command Queue Engine enabled
[ 1.567313] mmc2: new HS400 Enhanced strobe MMC card at address 0001
[ 1.570136] fsl-micfil-dai 30080000.micfil: GET IRQ: 14
[ 1.574751] mmcblk2: mmc2:0001 DG4016 14.7 GiB
[ 1.578942] fsl-micfil-dai 30080000.micfil: GET IRQ: 15
[ 1.583591] mmcblk2boot0: mmc2:0001 DG4016 partition 1 4.00 MiB
[ 1.588700] fsl-micfil-dai 30080000.micfil: GET IRQ: 16
[ 1.594736] mmcblk2boot1: mmc2:0001 DG4016 partition 2 4.00 MiB
[ 1.599850] fsl-micfil-dai 30080000.micfil: GET IRQ: 17
[ 1.606488] mmcblk2rpmb: mmc2:0001 DG4016 partition 3 4.00 MiB, chardev (237:0)
[ 1.621321] mmcblk2: p1
No sign of mmcblk1:p1 or p2
... and forgive my fsl-community-bsp n00b-ness. When I unzipped the wic.gz it looked about the right size of a sdcard image so I just dd'd it. After more inspection I see this .wks file in the deploy directory so I did this command wic create core-image-base-imx-imx-boot-bootpart.wks -e core-image-base which generated:
core-image-base-imx-imx-boot-bootpart-202007291817-mmcblk.direct
core-image-base-imx-imx-boot-bootpart-202007291817-mmcblk.direct.p0
core-image-base-imx-imx-boot-bootpart-202007291817-mmcblk.direct.p1
core-image-base-imx-imx-boot-bootpart-202007291817-mmcblk.direct.p2
The core-image-base-imx-imx-boot-bootpart-202007291817-mmcblk.direct file isn't quite the same size as the unzipped .wic but close. So I assumed it was a complete sdcard imae and dd'd that and got same result. Although it appears the .wks file has 3 partitions and when I put my sdcard in pc to look at it, I only see the traditional boot and root partitions so I'm not 100% convinced I'm making the sdcard right ... (it's weird how I never noticed the time/date stamps changing of u-boot & kernel between the 3 sdcard flash attempts ... well 4 now) and could still be using the original NXP image ... but if so, I sure would like to know what in the world dd is doing.
I'm sure I'm probably doing something stupid ... but I don't know what I don't know.
Regards,
Brian
