New i.MX board

Hi folks,

I'm currently bringing up a new i.MX6q based board.

I've got u-boot working, but its clear that a lot of the iMX stuff is still using the old configuration system.

is the latest iMX stuff in u-boot mainline yet? if not, where should I be looking / what is considered a 'model platform', so that I can publish the best possible support for my board?

Would more work to move stuff to Kconfig be helpful? or is this in-hand somewhere?

Thanks,

-Ian

Hi, Ian:
What version is your u-boot version? there's some git repository
you can try:
1. git://git.denx.de/u-boot-imx.git
- which maintained by Stefano Babic, merged imx related
code with mainline u-boot.
2. https://github.com/Freescale/u-boot-fslc.git
- which matained by Otavio Salvador, have every branch in
mainline(2009.07 - 2014.07, 2014.10, 2015.01 etc...) with i.mx related patches.

Since i.mx6q pcie is supported in Otavio's git repository branch
"patches-2014.10", I think u-boot-fslc is support i.mx6q very well now, it booting into kernel only spend 0.3~0.5s.

If you have question which i.mx related, maybe you can also send
mail to meta-freescale to ask them.

regards,
Wally

Hello,

Just for clearness...

Please rely on U-Boot i.MX for it. The U-Boot FSLC tree is used to carry backports of development version over the current released one, plus Yocto Project BSP's specific patches like environment minor adjustments and like.

If you see the patches we are applying on top of upcoming 2015.01, they are only:

5d396c3 wandboard: Changed mmcroot variable so kernel 3.10.31 boots c6d9bf7 iMX6: Change mmcroot to use fixed mmc block index for USDHC be9a741 embestmx6boards: Change default bootenv configuration ea9b369 wandboard: Use 32bit color depth for Fusion LCD 8e88da8 mx6sabresd: Use LDO dtb file until LDO bypass support is added 7d0f155 mx6slevk: Use LDO dtb file until LDO bypass support is added dcd7ac3 mx6sabresd: Use mmcblk0 for CONFIG_MMCROOT

So it is really minor changes, nothing big.

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Clear as mud, chaps :-)

I presume fslc is "mainline", as in git://git.denx.de/u-boot.git

This is what I've use thus far and it seems to work well, except a small problem with PCIe

What is u-boot i.mx? googling didn't enlighten me.

This comment worries me:

This suggests that u-boot i.imx is using fslc as a dumping ground for stuff they don't want to maintain, rather than treating it as an upstream with which to merge patches. I hope this is not the case? The distinction is subtle, so perhaps I've just misunderstood?

Who is doing the backports? and why is fslc considered "behind" ?

-Ian

This is the U-Boot i.MX custodian tree[1]; when working on development version you need to handle different trees depending on the subsystem so you can use the 'cutting edge' code.

1. http://git.denx.de/?p=u-boot/u-boot-imx.git

No. I may have not been clear but the pristine point is U-Boot i.MX

Basically i.MX related stuff does:

<dev tree> -> U-Boot i.MX -> U-Boot ARM -> U-Boot

The U-Boot FSLC is the fork we use for the meta-fsl-arm and meta-fsl-arm-extra. Some environment changes are too narrow for upstream, or are workarounds and a more elegant solution is under cooking.

If you look at the set of changes we carry there they are minimal. We upstream all we can as it is the best route for avoiding same issue for the bigger number of user and to reduce the amount of code we need to maintain.

I hope it is clear now.

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Not sure which version you are using, but if you use 2015.01 we have kconfig in place.