How to create a bootable uSD card from a Yocto build for the iMX28evk?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to create a bootable uSD card from a Yocto build for the iMX28evk?

10,207 Views
colinmoloney
Contributor II

I am trying to bring our old build of an iMX28 that was using Yocto dizzy on Ubuntu 14.04 to rocko on Ubuntu 16.04.

I have started with:

    repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b rocko

change the default local.conf to have:

   MACHINE ??= 'imx28evk'
   DISTRO ?= 'fslc-framebuffer'

and successfully built the 'core-image-minimal' with files in tmp/deploy/images/imx28evk/...

I am now trying to burn this onto an sd card to test.  Under the new system, the default output is now 'wic.gz' not 'sdcard' and I'm trying to use the command:

    wic create .../sources/meta-freescale/wic/imx-uboot-mxs-bootpart.wks -e core-image-minimal

It creates a file called "<name>.direct", but when burn onto a card it only has two partitions.  From the .wks file I would expect 3 partitions.  I would also expect one of them of type 53 (or 'S') to hold the bootstream.   The .wks file cannot have a partition type of 53 it is restricted to only a few know file system types.

Q. As the iMX28 ROM code is looking for a DOS partition of type 53 for it's boot stream, what do I need to do to get wic (or some other tool) to create the proper SD card?  

Under the old dizzy the final output called "<name>.sdcard" had everything required and could be 'dd'ed directly onto a card.

Colin Moloney

Labels (2)
12 Replies

5,842 Views
katte
Contributor II

Hi, I have the same problem, have you find a solution?

0 Kudos

5,842 Views
colinmoloney
Contributor II

Hi Marco,

    I was able to  get the 'morty' version of YOCTO to build an image for the imx_evk28 that booted correctly.

    The changes, discussed above with Otavio, look like they will work on 'rocko' version of YOCTO.  I've tried the changes as a quick hack of my workspace and they produced a bootable uSD.  I haven't got any further because higher priority work has interrupted me.

    I am currently trying to get our product to build for 'morty'  (using imx-bootlets, not u-boot).  It is booting but I'm still getting all the init scripts in place for our hardware and applications. So I'm very close to succeeding there. After that I'll port it to  'rocko' and hopefully u-boot too.

Colin

0 Kudos

5,842 Views
erikraynolds
Contributor III

can't boot image for imx8qm created out of sumo

repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml

MACHINE=imx8qmmek DISTRO=fsl-imx-xwayland source ./fsl-setup-release.sh -b bld-xwayland

5,842 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Colin Moloney,

There wic.gz format was introduced on the latest branches and it’s a compressed format similar to the sdcard format. I’m investigating if you can add the sdcard format so you get an .sdcard file as output as well.

In the meantime, you should be able to extract and write on an SD card with something like:

$ gunzip -c <IMAGE>.wic.gz | sudo dd of=/dev/sdX bs=1M  iflag=fullblock oflag=direct conv=fsync

I hope this helps!

Regards,

0 Kudos

5,842 Views
colinmoloney
Contributor II

Thanks gusarambula,

    but the problem is not writing the image to the card, it is that the image only contains two partitions and that the boot partition is not of type 53 that the iMX28 needs.

- CM

I have since followed https://www.nxp.com/docs/en/application-note/AN12024.pdf  and used YOCTO 'morty'.   This produces a .sdcard output that has three partitions and with the boot partition of type 53.  The evk only partly boots: u-boot runs and load the kernel but the kernel waits forever for mmcblk0p3 to become ready.  The card is OK because I can mount it on a PC and observed the 'p3' partition.  Interestingly there is no /lib/modules directory in the root file system; has the structure of linux changed or has the build not built everything?

-CM

0 Kudos

5,842 Views
OtavioSalvador
Senior Contributor II

So I did check what was missing.

Please apply following two patches to OE-Core / Poky:

[1/2] parted: add ontrack DM6 aux3 support - Patchwork 

[2/2] wic: add ontrack DM6 aux3 support - Patchwork 

and these two in meta-freescale:

[1/2] u-boot-fslc-mxsboot: Add dtc as build dependency - Patchwork 

[2/2] wic: Fix image generation for i.MX MXS SoC family - Patchwork 

Let me know if it works for you.

5,842 Views
colinmoloney
Contributor II

Thanks Otavio,

    I applied the patches and began a clean build.  The image is almost

correct:

There are 3 partitions and the FAT32 and the EXT4 look OK but the boot

stream on partition 1 of type 0x53 has the wrong offset in the header.

The file

"core-image-minimal-imx28evk-20180427075602.rootfs.uboot-mxsboot-sdcard"

starts:

00000000  33 22 11 00 01 00 00 00  01 00 00 00 01 00 00 00

3"..............

00000010  00 00 00 00 00 00 00 00  01 00 00 00 04 08 00 00 

................

00000020  28 05 00 00 00 00 00 00  00 00 00 00 00 00 00 00

(...............

00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

................

*

00000800  97 73 ba 38 41 db b9 70  a6 15 cb b4 9a 1b 1f 4d

.s.8A..p.......M

00000810  f8 40 89 5e 53 54 4d 50  01 01 01 00 9b a4 00 00

.@.^STMP........

00000820  09 00 00 00 00 00 00 00  01 00 07 00 06 00 01 00

................

00000830  01 00 00 00 73 67 74 6c  40 ad e3 a1 32 0d 02 00

....sgtl@...2...

and so would only be correct if burnt to address 0x00100000 (sector

0x0800) but it is burnt to address 0x00000400 and so the offset in the

header should be 0x000000006.

I tried adding '-p 2' to the line in

meta-freescale/classes/image_types_fsl.bbclass (just as a test):

    IMAGE_CMD_uboot-mxsboot-sdcard = "mxsboot -p 2 sd

$/u-boot-$.$ \ $/$.rootfs.uboot-mxsboot-sdcard"

and the file

"core-image-minimal-imx28evk-.......rootfs.uboot-mxsboot-sdcard"

is now:

00000000  33 22 11 00 01 00 00 00  01 00 00 00 01 00 00 00

3"..............

00000010  00 00 00 00 00 00 00 00  01 00 00 00 06 00 00 00 

................

00000020  28 05 00 00 00 00 00 00  00 00 00 00 00 00 00 00

(...............

00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

................

*

00000800  97 73 ba 38 41 db b9 70  a6 15 cb b4 9a 1b 1f 4d

.s.8A..p.......M

00000810  f8 40 89 5e 53 54 4d 50  01 01 01 00 9b a4 00 00

.@.^STMP........

00000820  09 00 00 00 00 00 00 00  01 00 07 00 06 00 01 00

................

00000830  01 00 00 00 73 67 74 6c  40 ad e3 a1 32 0d 02 00

....sgtl@...2...

and the .wic looks OK too.  I couldn't make the 'wic' command

work so I just unzipped the .wic.gz and used 'dd' to burn the image.

[ The command "wic write  sync

didn't know what 'wic'  was.]

It now load u-boot which then loads Linux and boots and mounts

/dev/mmcblk0p3 as root.

So, obviously I shouldn't put a hard coded '-p 2' in the

IMAGE_CMD_uboot-mxsboot-sdcard.

How should the location of the bootstream be handled?

The .wks.in template is translated into

    part u-boot --source rawcopy

--sourceparams="file==core-image-minimal-imx28evk-20180430014159.rootfs.uboot-mxsboot-sdcard"

--ondisk mmcblk --fstype=ontrackdm6aux3 --align 1

    part /boot --source bootimg-partition --ondisk mmcblk

--fstype=vfat --label boot --active --align 4096 --size 16

    part / --source rootfs --ondisk mmcblk --fstype=ext4

--label root --align 4096

    bootloader --ptable msdos

and the offset of the bootstream is already embedded in

"core-image-minimal-imx28evk-20180430014159.rootfs.uboot-mxsboot-sdcard".

Either:

1. 1. the position of the bootstream needs to  be extracted

from the .wks when building the rootfs.uboot-mxsboot-sdcard

2. 2. the definitions/placements in the .wks need to be dynamic

and move partitions around depending on how

rootfs.uboot-mxsboot-sdcard was built

1. 3. the offset in the header of the

bootstream needs to be adjusted at the time

the .wic is written to the sdcard.

4. something I haven't thought of...

Regards,

Colin Moloney

0 Kudos

5,842 Views
OtavioSalvador
Senior Contributor II

Hello, thanks for the test.

Please apply those changes (http://termbin.com/qzxh ) and see if this works for you.

If it does, I send a new patch version for merge.

0 Kudos

5,842 Views
colinmoloney
Contributor II

Hi, sorry about the delay I've been on a different project for a few weeks. 

1)  I'm trying to  test your fix but even after 'rm -rf tmp' I can't get the bitbake to complete the do_image_wic step. I complains that  the .wks file doesn't exist.  The .wks.in exists.  What step creates the .wks from the .wks.in?  I can't get it to re-perform that step.

2) The change in http://termbin.com/qzxh is to set the 'align' to 1MiB so that it matches the internal default inside mxsboot, of 2048 blocks  [Which only works if the boot partition comes first in the list of partitions.]

Wouldn't it be more controlled to set the origin a little more explicitly so it is visible reading the scripts without needing to know the source code for mxsboot? eg.  (still only works if the boot is the first partition, but is explicit)

a) In build/conf/local.conf

   # Set origin to  1MiB and the -p arg to  mxsboot to match (in blocks/sectors)

   MXSBOOT_SD_BOOTORIGIN = "1"
   MXSBOOT_SD_ARGS = "-p $(expr 2 '*' ${MXSBOOT_SD_BOOTORIGIN})"

b) In sources/meta-freescale/wic/imx-uboot-mxs-bootpart.wks.in

   part u-boot --source rawcopy           --sourceparams="file=${IMAGE_NAME}.rootfs.uboot-mxsboot-sdcard" --ondisk mmcblk --fstype=ontrackdm6aux3                       --align ${MXSBOOT_SD_BOOTORIGIN}

c) In sources/meta-freescale/classes/image_types_fsl.bbclass

    IMAGE_CMD_uboot-mxsboot-sdcard = "mxsboot ${MXSBOOT_SD_ARGS} sd ${DEPLOY_DIR_IMAGE}/u-boot-${MACHINE}.${UBOOT_SUFFIX} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.uboot-mxsboot-sdcard"

BTW, does the OE .wic system have a way of specifying the origin of the partitions explicitly?  A bit like a linker might place objects in memory, working around explicit origins and sizes?

Colin Moloney

0 Kudos

5,842 Views
gusarambula
NXP TechSupport
NXP TechSupport

OtavioSalvador‌, would you know if this is a known issue with the image generated on the rocko branch?


Regards,

0 Kudos

5,842 Views
OtavioSalvador
Senior Contributor II

I did a look at the code and it does seem to be broken. I will work on a fix for this on Monday :-)      

0 Kudos

5,842 Views
OtavioSalvador
Senior Contributor II

Ok, so I got a patchset together to fix the missing bits for it to work. I will be sending it to OE-Core and meta-freescale. Once merged, they can be backported ...

0 Kudos