I have a project for the Sabresd board (Yocto).
What do I need to change to compile this project for an I.mx6d (dual)?
We normally use one kernel image for all i.MX6 SOCs. But for uboot, each board has each config, but for i.mx6d, it should be OK to use i.mx6q's config.
Which kernel version you are using? As far as I know, for L3.10.17, no need to change anything for compiling i.mx6d, all i.MX6 platforms use same config.
I'm using Dora 1.5, so I think it is kernel 3.10.
So there is no difference in the compilation for the uBoot either then?
I just wanted verify that I don't need to do any modification in the Linux image when running with an i.MX6D (I'm basing my image on SabdeSD).
I know that the SabdreSD has some CPU controlled voltage regulator, which we don't have in our design (plus we are using i.MX6D).
Right now I can get the kernel to boot on a SabreSD board, but in our custom board it hangs after "Starting kernel ...." after u-boot.
Just wanted to make sure that I don't need to change anything to run on an i.MX6D.
If the regulator is not setup, would that cause this kind of problem or would I see some print out from the kernel bootup?
No, all ARM cores share a regulator, if regulator has problem, then your uboot will not be able to boot.
I think the problem is not caused by core number, but the difference of board design. You can add “nosmp” to uboot cmdline, then kernel will only boot up with one core.
Freescale Semiconductor Shanghai
Before the Linux kernel is started, will the .dtb be applied?
If so, can there be any problem there, I have missed to change something the .dts/dtsi, so it causes the processor to stop?
Since the designed (how the power is provided) between the SabreSD and our custom board is different?
dtb will be loaded to memory before kernel is started, for your case, I think you may need to enable early printk to see whether we can see any log when failed. After enable early printk in menuconfig, you need to add "earlyprintk" in cmdline to enable it.
I managed to get it up and running.
Seems like there were too much ripple on our power to the ARM, so then we got an intermittent hanging of the processor.
Retrieving data ...