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

[Stephen Munnings]

-----Original Message-----
From: angolini at gmail.com [mailto:angolini at gmail.com] On Behalf Of Daiane Angolini
Sent: Thursday, June 19, 2014 10:46 AM
To: Stephen Munnings
Cc: meta-freescale at yoctoproject.org
Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

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



Hi Daiane,

Thanks for the fast reply.

Yes, I do have my own meta layers.  (one for BSP, one for distro, and one for the application(s))
Yes, I know I can use any bootloader.
In this case, one alternative is to move back to Uboot 2013.10 (realized in my own layers, since it is no longer in the meta-fsl-arm* layers).
It is possible I would also have to "move back" the Linux kernel version also.
This is still a considerable amount of work (but far less than in some other build scenarios)

I apologize for the confusion, it is indeed a typo.  The two versions of UBoot I was referring to were 2013.10 and 2014.01 (reversed 0 and 1)
Since we have been developing using the Wandboard as a reference design, we have been copying a lot of yocto setup from the Wandboard recipes.
The UBoot for both cases (dora and daisy) is u-boot-fslc - with a great big whacking patch (generated by git) applying our local changes, requested by our BSP layer for our board.
A similar arrangement was also used for our Linux Kernel with its driver and configuration changes.
Interestingly, our patch needed only very minor modifications to apply to u-boot-fslc_2014.01  (a few line number changes and the formatting of the entries in common/Makefile)
We have avoided, as much as possible (which is almost completely) any changes to the supplied meta layers, with all changes implemented by patches and over-rides in our own layers.
This is why I felt it would be relatively easy to migrate to daisy - and some of our bbappend recipes needed some changes for that. (especially version numbers as the versions changed) 

So, the include file changes are changes from u-boot-fslc_2013.10 to u-boot-fslc_2014.01  (checked)
I am not sure who was responsible for these changes, but they appear to have been made without appropriate consideration for upgrade compatibility.

It also appears that there is no fast and easy solution.  (e.g. optional enablement of the original PAD names, or a sed script (or similar) to run the source files through to convert from old names to new names)

Anyway, unless someone has a fast solution, I guess it is back to dora, and a note kept on the extra effort required when/if we move forward past dora.

Regards,

Stephen Munnings