On Mon, Jan 12, 2015 at 7:48 AM, Ian Molton imolton@ad-holdings.co.uk wrote:
On 10/01/15 12:34, Otavio Salvador wrote:
On Fri, Jan 9, 2015 at 9:35 PM, Wally Yeh
wally.yeh@atrustcorp.com wrote:
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. Just for clearness...
Please rely on U-Boot i.MX for it
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 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
This comment worries me:
The U-Boot FSLC tree is used to carry backports of development version over the current released one.
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" ?
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.