[meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Daiane Angolini]

On Thu, Jun 19, 2014 at 11:02 AM, Stephen Munnings
<Stephen.Munnings at nuvation.com> wrote:
> Hi all,
>
> I am working on a commercial project.
>
> We have been using Yocto for the build tools (branch - dora) and including a
> Qt application as part of the process.
>
> We have designed a custom board based on the IMX6 (single) processor and
> fairly close to the wandboard in general - so we could use Wandboards as the
> evaluation and early development tools.
>
> As part of the wrap-up of the project, I am (re)creating the build
> environment for our project.
>
> I decided (as an experiment) to try and move the project forward to the
> daisy branch - which should have been relatively painless.
>
> After getting over a few (minor) hurdles, when all seemed to be going quite
> well, I hit the killer...
>
> Our custom u-boot was developed with 2013.10 (seems to be the "standard" for
> branch dora)
>
> When I tried to get our u-boot compiled in daisy, it switched to version
> 2014.01 - shouldn't be much of a problem.
>
> HOWEVER.......
>
> This is when I discovered that our <board>.c file craps out all over the
> place because Freescale (I assume it is Freescale) changed all the pin PAD
> names (well maybe not all, but a large enough number) in the standard
> include files that are part of Uboot 2014.10.  They are in
> …/arch/arm/include/asm/arch-mx6/*.h
>
> Over and above that, they did not keep the old names for compatibility!
>
> Does somebody have a utility that I can run the source code through to
> convert all the old names to the new names?  If they do, I would love to
> know about it.
>
> I estimate that there are at least 45 different PAD names that were changed,
> and to fix this problem, I have to go through and manually scan the old and
> new include files, decide which old names match to which new names, and then
> make all the edit changes in the source files (and hope I did not screw this
> up somewhere).
>
> I am guessing that the folks at Wandboard.org had to navigate all this pain
> too.
>
> Some of the changes seemed particularly arbitrary.  Changing Uart pin names
> from ..._TXD to ..._TXDATA, and similarly for RXD, for example.
>
> I can only guess what this is likely to do to my Linux kernel code.  (I
> think they use common include files at some point).
>
> I didn’t even try to go down that road yet.
>
> I guess I could set up one of my yocto layers to go back to using 2013.10
> version of u-boot and the previous version of Linux – with liberal copies of
> recipes, etc., from the dora branch.
>
> Either of these alternatives just uses too much time (costly time), though.
>
> Does anybody know a quick way through this mess, or should I just stick to
> dora?

Do you have your own meta layer? Do you have your own machine file?
The main purpose of using yocto is that you can override a lot of
"default configurations"

So, you should be able to use *any* bootloader, if you configure it
correctly. Even if you are using another
u-boot version, and you keep this recipe in your own metalayer, there
is no reason for not working (other than the
toolchain version upgrade, that may cause some problem)

I mean, create your own meta layer, copy over the recipe file for
*your* u-boot, and make it work.

>
> My guess is that sticking to dora is the way (for now).

for now, yes. But you cannot stay on dora forever.

So, next time, you will already know you must keep one eye on your
stable branch, and the other eye on the master branch.


>
>
>
> Does anybody know why developers would go through all the painful work of
> changing all those names in the include files, and then have to change all
> the .c files to match, and finally, make other developer’s .c files need to
> go through the same transformation?

I'm confused in this point. You mentioned u-boot 2014.10 at some point
of your email. as you may imagine u-boot 2014.10 does not exist
already.

Of course it may be a typo. However, I wonder if you realized there
are 2 providers for u-boot (u-boot-imx and u-boot-fslc) And maybe this
huge
gap you've noticed, could be caused by this.

Can you, please, double check?

Daiane