Hello,
We are having an old project upgraded in order to increase cpu power, to do so we are changing from imx6s MCIMX6S7CVM08AC to imx6d MCIMX6D7CVT08AE, which are supposed to be pin to pin compatible.
I've been able to boot uboot, but my emmc doesn't appear :
MMC: FSL_SDHC: 0
MMC Device 1 not found
*** Warning - No MMC card found, using default environment
It used to show on Imx6s:
MMC: FSL_SDHC: 0, FSL_SDHC: 1
after that of course I can't do anything related to emmc for instance :
=> ums 0 mmc 0
MMC: no card present
** Bad device mmc 0 **
The only thing I changed is to configure in uboot MX6Q instead of MX6DL plus changing the .cfg file with my ddr calibration values. I've been running the DDR calibration tools with my custom DDR but that didn't give any real improvement. I'm still able to boot u-boot but nothing after that.
Can you point me in the right direction, is there any minimal configuration that I can use to boot linux on emmc ?
On our former imx6s we had to write those values to the fuses, shall we do the same (I don't want to rush into that since we don't have that much proto boards), besides I can't find much info regarding those values either :
fuse prog 0 5 0x00004060
fuse prog 0 6 0x10
I've also been trying to boot linux on RAM with mfgtools, it seems that I'm able to load dtb, zImage however when u-boot try to boot the kernel + dtb I'm stuck at the "Starting Kernel..." line as if the memory was actually empty. There's also something quite confusing with my mfgtools version is that I'm never actually explaining what was the rootfs I want to use is. With imx6s I'm using :
Profiles/MODX6_Update/OS\ Firmware/firmware/rootfs.cpio.uboot
Profiles/MODX6_Update/OS\ Firmware/firmware/rootfs.tar.gz
For my new mfgtools I've just added a u-boot with imx6qd version and the dtb. From my point of view I don't see anything wrong with booting the same zImage and the same rootfs because both imx6s and imx6d are using cortexa9, so to me changing dtb and uboot is supposed to be enough correct?
Best regards,
Yann
Solved! Go to Solution.
It turns out the problem did not comes from device tree, but as @art said, it came from the uboot memory calibration.
We had to use a xlsx configuration tool from NXP called "I MX6DQSDL DDR3 Script Aid V0 10.xlsx" and use that file to calibrate our ram with imx6dl, and then reporting all the register values in our uboot .cfg file.
Also answering my questions :
> Is it correct to use the same kernel for imx6s and imx6d ?
indeed it is, however one need to integrate the correct pin control in kernel.
> Is it ok to use the same dts that was working for imx6s and simply changing the dts included from imx6dl.dtsi to #include "imx6q.dtsi" ?
indeed it is and it is the recommended, the only difference shall be here between the different board.
> Also can you clarify the link regarding serial devices between what I can configure in Uboot:
indeed naming is at first misleading but uboot's UART4_BASE correspond to ttymxc3 on Linux.
Moving forward on this, I have been able to use my emmc with filling the fuses.
What achieved so far is to flash uboot on emmc via :
ums 0 mmc 0.1
then from host :
sudo dd if=u-boot.imx of=/dev/sda bs=512 seek=2
However I'm still stuck on the same place regarding the other topic, I'm not able to boot my kernel be it from mfgtools or from emmc. For some reason my kernel won't launch.
Booting from mmc ...
reading uImage
4285728 bytes read in 156 ms (26.2 MiB/s)
reading imx6q-new.dtb
43252 bytes read in 16 ms (2.6 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
Image Name: Linux-4.1.46-+gcd3ecbf
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4285664 Bytes = 4.1 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Kernel Image ... OK
Using Device Tree in place at 18000000, end 1800d8f3
ldo_bypass value read from DT = 1
Starting kernel ...
Do you have any leads for me?
To sum it up I'm able to load with mfgtools or from emmc my uboot, kernel and dtb, but I have trouble understanding why the kernel is not able to boot after that.
About the dts I'm using the same dts, simply changing
#include "imx6dl.dtsi"
to :
#include "imx6q.dtsi"
Can you confirm the following : kernel shall not change between imx6d and imx6s ? only dts shall change? On rootfs side I can use the same one since both have cortex a9 cpus ?
Hi, do you have any pointers for me?
The most likely cause of the issue is that the i.MX6Solo and i.MX6Dual
processors have slightly different integrated peripherals set, memory map and
clock controller sructure, and, therefore, different hardware initialization
sequence. So, the hardware initialization sequence for i.MX6Solo cannot be
directly applied to i.MX6Dual and may lead to system failure.
The initialization of the DDR controller and basic integrated peripherals is
performed on the early boot stage when the Boot ROM code processes the Device
Configuration Data (DCD) table, located in the beginning of the boot image. For
details on the DCD itself and boot image structure, please refer to the Section
8.6 "Program image" of the i.MX6Dual/Quad Reference Manual document, available
on the processor's Documentation web page:
For the information on how to build a custom DCD table and memory-specific
parameters, please refer to the "Customizing the i.MX custom board code" section
of the i.MX Linux Porting Guide document for the Linux BSP you use.
Best Regards,
Artur
Hello Arthur,
Thanks for the answer, I think what you said would be right if I could not boot uboot, which I can. From what I can see in the document you mentioned that doesn't seem to explain what I'm witnessing. If I'm wrong can you elaborate?
I would assume that since I'm able to boot uboot correctly from emmc and from mfgtools or uuu, hardware initialization is probably correct?
The problem I'm facing is at the handover from uboot to kernel moment. From my point of view, the only matter at this stage is whether my kernel is correctly compiled for my target and if the dtb is also describing properly my hardware.
Can you validate my two hypothesis :
> Is it correct to use the same kernel for imx6s and imx6d ?
> Is it ok to use the same dts that was working for imx6s and simply changing the dts included from imx6dl.dtsi to #include "imx6q.dtsi" ?
> Also can you clarify the link regarding serial devices between what I can configure in Uboot:
#define CONFIG_MXC_UART_BASE UART4_BASE
#define CONFIG_CONSOLE_DEV "ttymxc3"
and the dts uart linked to ttymxc3?
What can be a very minimal dts to boot with my board?
Best regards,
It turns out the problem did not comes from device tree, but as @art said, it came from the uboot memory calibration.
We had to use a xlsx configuration tool from NXP called "I MX6DQSDL DDR3 Script Aid V0 10.xlsx" and use that file to calibrate our ram with imx6dl, and then reporting all the register values in our uboot .cfg file.
Also answering my questions :
> Is it correct to use the same kernel for imx6s and imx6d ?
indeed it is, however one need to integrate the correct pin control in kernel.
> Is it ok to use the same dts that was working for imx6s and simply changing the dts included from imx6dl.dtsi to #include "imx6q.dtsi" ?
indeed it is and it is the recommended, the only difference shall be here between the different board.
> Also can you clarify the link regarding serial devices between what I can configure in Uboot:
indeed naming is at first misleading but uboot's UART4_BASE correspond to ttymxc3 on Linux.