iMX6ULL Booting Linux OS - UUU vs Manual Partition

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

iMX6ULL Booting Linux OS - UUU vs Manual Partition

582 Views
SamM
Contributor II

Using iMX6ULL14x14EVK.
With the current Linux release Linux 6.6.52_2.2.0 demo files.
Booting from an SD card.

If I download the bootloader and image using UUU everything looks good, Linux boots with no errors.
uuu -b sd_all u-boot-imx6ull14x14evk_sd.imx imx-image-full-imx6ul7d.wic

Similarly if I download with dd Linux boots with no errors
sudo dd if=imx-image-full-imx6ul7d.wic of=/dev/sdb bs=1M && sync
sudo dd if=u-boot-imx6ull14x14evk_sd.imx of=/dev/sdb bs=1k seek=1 conv=fsync

However if I follow the instructions from section 4.3.3 onwards in the i.MX Linux User's Guide to partition and download the bootloader/image/rootfs manually (using the default VFAT partition) then I see multiple errors at boot:
[FAILED] Failed to start Network Time Synchronization
[FAILED] Failed to start User Login Management
[FAILED] Failed to start Hostname Service

Also the display output is different, I see a terminal rather than the desktop.

I've checked that the *.dtb files are the same across all methods.

Am I missing something or is there a difference between the rootfs/image within the .wic and the separate rootfs/image?

Labels (2)
0 Kudos
Reply
8 Replies

352 Views
SamM
Contributor II

I've since had the same result from the Pre-defined Raw Address alternative described in the manual, and from both methods with the image files build from source.

I've tried to take things a bit further with no success so far.
If the .wic works, it makes sense to look at how it is created. The WKS_FILE variable is set to "imx-uboot-bootpart.wks.in"

Inspecting that file we see

part u-boot --source rawcopy --sourceparams="file=${UBOOT_BINARY}.tagged" --ondisk mmcblk --no-table --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

I think bootimg-partition pulls in the files listed in IMAGE_BOOT_FILES, which is "zImage imx6ull-14x14-evk.dtb <various other .dtb files> tee.bin uTee-6ullevk"

I tried creating the partitions manually, respecting the size and alignment settings in the .wks and including all of the above files.

I got exactly the same errors.

The next thing I plan to try is to rebuild the .wic in cooked mode to confirm that still works

0 Kudos
Reply

575 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

It seems that there is an issue in kernel/rootfs flashing stage, please try with Pre-defined raw address instead VFAT partition.

Best regards.

0 Kudos
Reply

452 Views
SamM
Contributor II

I've now tried both the VFAT and Pre-defined fixed address methods on the demo files, and a set of files rebuilt from source using imx-image-core.

Same result in all cases, errors on User Login Management and Network Time Synchronisation.

I've also tried with/without uTee as I noticed that is enabled when downloading the .wic but it made no difference.

Downloading the .wic file continues to work in all cases.

 

I've run out of ideas for now, and we're back to the original question.
Why does downloading the .wic work correctly, while downloading the image/rootfs/bootloader manually results in errors at boot?

0 Kudos
Reply

478 Views
SamM
Contributor II

I eventually got the system to boot with the Pre-defined raw address method.
The commands listed in the Linux User's guide do not work for Linux 6.6.52_2.2.0 because the zImage has increased in size beyond the space reserved for the first partition.

I started the first partition at 20560 (rather than 20480) and wrote the .dtb file to the beginning of that partition, then adjusted U-Boot to match.

However I get the same result as the VFAT partition method.
Linux boots but I get multiple errors:
[FAILED] Failed to start Network Time Synchronization
[FAILED] Failed to start User Login Management
[FAILED] Failed to start Hostname Service

So it still seems that there is some difference between the .wic and the separate image/rootfs in the demo files.

I am running bitbake imx-image-core overnight and will retry with that image tomorrow.

Do you have any other suggestions?

0 Kudos
Reply

513 Views
SamM
Contributor II

Can you provide any more information on the Pre-defined raw address method of copying the kernel image and .dtb file?

Particularly how the default U-Boot environment variables should be changed?

I would guess that I need to use U-Boot read command rather than fatload, but I'm not sure what the correct <blk#> and <cnt> arguments are.

0 Kudos
Reply

503 Views
SamM
Contributor II

Changing the following U-Boot environment variables seems sensible

loadfdt = mmc read ${fdt_addr} 5000 59

loadimage = mmc read ${loadaddr} 800 484a

fdt is able to read the device tree at ${fdt_addr} after load.

 

However the system now hangs at Starting kernel ...

Perhaps this is because my zImage is wrong? The manual says

... zImage file created when using the imx_v7_defconfig
configuration file ...

What is this configuration file and how do I obtain the corresponding zImage file?

0 Kudos
Reply

553 Views
SamM
Contributor II

That method isn't 100% clear to me

The command provided is:
sudo dd if=zImage_imx_v7_defconfig of=/dev/sdx bs=512 seek=2048 conv=fsync

With the note:
The file zImage_imx_v7_defconfig refers to the zImage file created when using the imx_v7_defconfig configuration file, which supports both i.MX 6 and i.MX 7 SoCs

The zImage files included in the demo files are zImage and zImage-imx6ul7d.bin
Which (or both/neither?) of those is created using the imx_v7_defconfig configuration file?

0 Kudos
Reply

549 Views
SamM
Contributor II

Also unclear on this note:
The later method needs to modify the U-Boot default environment variables
for loading the kernel image and DTB.

I can see that loadimage and loadfdt now fail in U-Boot.
Do I resolve that by changing fdt_addr and loadaddr? Or do I need to use a different bootcmd?

0 Kudos
Reply