Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Stephen Munnings]

[-- Attachment #1: Type: text/plain, Size: 3272 bytes --]

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?
My guess is that sticking to dora is the way (for now).

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?

It seems to have been a really short-sighted move by whoever did it.
However, there are sometimes other (good) reasons to do this kind of thing that nobody ever finds out about.
Maybe.


--
Stephen Munnings
Sr. Design Engineer | NUVATION ENGINEERING
519.594.0976
stephen.munnings@nuvation.com<mailto:stephen.munnings@nuvation.com> | www.nuvation.com<http://www.nuvation.com>


[-- Attachment #2: Type: text/html, Size: 8814 bytes --]

Re: 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@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

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Stephen Munnings]

-----Original Message-----
From: angolini@gmail.com [mailto:angolini@gmail.com] On Behalf Of Daiane Angolini
Sent: Thursday, June 19, 2014 10:46 AM
To: Stephen Munnings
Cc: meta-freescale@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@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

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Daiane Angolini]

On Thu, Jun 19, 2014 at 12:46 PM, Stephen Munnings
<Stephen.Munnings@nuvation.com> wrote:

> 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.

Well, if you're using u-boot-fslc, you can git blame here
http://git.denx.de/?p=u-boot.git;a=summary in order to find *who*

I'm not a u-boot community frequent user/member. I mean, I don't
follow their changes, so I cannot say why they decided to change so
much from one release to another. But, it's an open community and you
can participate.

>
> 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)

One thing is the YP version, the other thing is the u-boot/kernel version.

>
> 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.

Let's wait for someone to comment on this.

Daiane

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Otavio Salvador]

Hello Stephen,

As other points has been covered in Daiane's reply I will focus on the pads.

On Thu, Jun 19, 2014 at 11:02 AM, Stephen Munnings
<Stephen.Munnings@nuvation.com> wrote:
...
> 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!

The PADs change is being worked during several releases in U-Boot and
it is part of a bigger goal which is to support SPL for i.MX6 and as
result to support multiple SoC and board variants with a single
U-Boot. The PADs has been renamed to follow mostly the mainline naming
schema and this does impact previous code.

During the change, we (U-Boot community) ported all boards in the
source code but as you keep your board in an internal fork you need to
handle it yourself.

I hope this clarifies a little about it.

Regards,

-- 
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

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Fabio Estevam]

On Fri, Jun 20, 2014 at 2:18 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> During the change, we (U-Boot community) ported all boards in the
> source code but as you keep your board in an internal fork you need to
> handle it yourself.

Tha's correct. In order to avoid such pain in the future, Stephen
could add his board support to mainline U-boot.

This way, whenever an API change happens, the board will be
automatically converted.

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Stephen Munnings]

-----Original Message-----
From: Fabio Estevam [mailto:festevam@gmail.com] 
Sent: Friday, June 20, 2014 2:17 PM
To: Otavio Salvador
Cc: Stephen Munnings; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

On Fri, Jun 20, 2014 at 2:18 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:

> During the change, we (U-Boot community) ported all boards in the 
> source code but as you keep your board in an internal fork you need to 
> handle it yourself.

Tha's correct. In order to avoid such pain in the future, Stephen could add his board support to mainline U-boot.

This way, whenever an API change happens, the board will be automatically converted.
-----End Original Message-----


Thanks Fabio and Otavio.

Even if we were going to put this board in the mainline U-boot (somewhat unlikely, as the board itself is a sub-component of a larger system, and not likely to ever hit the market as the "board by itself"), it was (and still is) under development.  I don't think it is very wise (if it is even allowed) to put an unfinished board into the U-boot mainline.
The only issues I have here are:
 a) The lack of notification that such a change had happened between dora and daisy.  And I don’t see how I can blame anybody for that, as I am not sure how that information should/would/could have been sent to the right target audience in the appropriate time frame(s) anyway.  Timely responses to my query (which did happen) are sufficient, I think.
 b) The lack of the "conversion tool".   Apparently Eric Nelson of Boundary Devices did much of this work (thanks Eric <genuine> ), but the conversion tool seems to have "gone missing".  That would have solved everything in a reasonably cost effective manner.  A pity it is MIA!

For now, we will just stay with dora, and 2013.10.  At least we will now know some of the costs associated with moving forward if we ever need to.

-- 
Stephen Munnings 
Sr. Design Engineer | 519.594.0976 
www.nuvation.com

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Fabio Estevam]

On Fri, Jun 20, 2014 at 4:31 PM, Stephen Munnings
<Stephen.Munnings@nuvation.com> wrote:

> The only issues I have here are:
>  a) The lack of notification that such a change had happened between dora and daisy.  And I don’t see how I can blame anybody for that, as I am not sure how that information should/would/could have been sent to the right

meta-fsl-arm uses code from the U-boot project and build it.

The IOMUX change happened in the U-boot code, and all the boards that
are part of the project were properly converted.

There is no 'notification' on such projects. People who are working on
the upstream projects only care to not break the boards that are
supported by those projects.

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Eric Nelson]

Hi Stephen,

On 06/20/2014 12:31 PM, Stephen Munnings wrote:
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com] 
> Sent: Friday, June 20, 2014 2:17 PM
> To: Otavio Salvador
> Cc: Stephen Munnings; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?
> 
> On Fri, Jun 20, 2014 at 2:18 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
>> During the change, we (U-Boot community) ported all boards in the 
>> source code but as you keep your board in an internal fork you need to 
>> handle it yourself.
> 
> Tha's correct. In order to avoid such pain in the future, Stephen could add his board support to mainline U-boot.
> 
> This way, whenever an API change happens, the board will be automatically converted.
> -----End Original Message-----
> 
> 
> Thanks Fabio and Otavio.
> 
> Even if we were going to put this board in the mainline U-boot
> (somewhat unlikely, as the board itself is a sub-component of a larger
> system, and not likely to ever hit the market as the "board by itself"),
> it was (and still is) under development. I don't think it is very wise
> (if it is even allowed) to put an unfinished board into the U-boot mainline.
>
> The only issues I have here are:
>
> a) The lack of notification that such a change had happened between
> dora and daisy. And I don’t see how I can blame anybody for that, as I
>  am not sure how that information should/would/could have been sent to
> the right target audience in the appropriate time frame(s) anyway.
> Timely responses to my query (which did happen) are sufficient, I think.
>
> b) The lack of the "conversion tool". Apparently Eric Nelson of
> Boundary Devices did much of this work (thanks Eric <genuine> ), but the
> conversion tool seems to have "gone missing". That would have solved
> everything in a reasonably cost effective manner. A pity it is MIA!
> 

This script was kind of a glorified search and replace, and if you're
just updating one board, doing this by hand is tedious but not very
time consuming.

> For now, we will just stay with dora, and 2013.10. At least we will
> now know some of the costs associated with moving forward if we ever
> need to.
> 

I do think you're missing something. The pad changes I made were to
U-Boot, and there's no reason you can't stick with your 2013.10
version of U-Boot and migrate to a 3.10.17 kernel.

Changing the kernel is likely much more involved, since you should
switch to device-tree in the process, and no amount of tool helps there.

Your best bet is to closely track your differences from another board
that's already made the jump.

This is essentially what we do with our 20-some-odd custom boards
that tend to be variants of SABRE Lite/Nitrogen6x designs.

Regards,


Eric

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Stephen Munnings]

-----Original Message-----
From: Fabio Estevam [mailto:festevam@gmail.com] 
Sent: Friday, June 20, 2014 4:12 PM
To: Stephen Munnings
Cc: Otavio Salvador; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

On Fri, Jun 20, 2014 at 4:31 PM, Stephen Munnings <Stephen.Munnings@nuvation.com> wrote:

> The only issues I have here are:
>  a) The lack of notification that such a change had happened between 
> dora and daisy.  And I don’t see how I can blame anybody for that, as 
> I am not sure how that information should/would/could have been sent 
> to the right

meta-fsl-arm uses code from the U-boot project and build it.

The IOMUX change happened in the U-boot code, and all the boards that are part of the project were properly converted.

There is no 'notification' on such projects. People who are working on the upstream projects only care to not break the boards that are supported by those projects.

-----End Original Message-----

I understand all of that.
However, meta-fsl-arm did make the decision to move from Uboot_2013.10 to Uboot_2014.01, not retaining support for 2013.10.
Perhaps they thought that since the Uboot mainline projects were converted that there were no remaining issues with this. 
(And I am not complaining about those decisions)
But it still leaves a hole where a new project is currently being worked on (not yet moved to U-boot mainline) and its time frame includes the period where this work happened.
In my case, the time frame covering the movement from 2013.10 to 2014.01
This is not a complaint, just trying to cover off the facts.
As I said, I am not sure how this particular situation should best be handled.
Perhaps I should have read the release notes for the 2014.01 version - when I realized that daisy had moved to using 2014.01.
I am guessing that this was mentioned in there - amongst all the other stuff.
As Eric Nelson stated (in FSL community post), the patches were posted to the u-boot mailing lists.
However developers cannot spend an appreciable fraction of their valuable time simply trying to stay current on the mailing lists.
It is a sad fact of life - but with a big upside to it also - that there is just too much traffic to be constantly scanning for items of direct interest.
Again, if the conversion tool were still available (and it was not so very long ago that this happened) there would really be no issue here to speak of.
I do appreciate all the work that goes into all the maintenance that was done, and perhaps overreacted to the surprise of having all those constants changed.
I am still disappointed in only one thing - that the conversion tool no longer seems to exist.

-- 
Stephen Munnings 
Sr. Design Engineer | 519.594.0976 
www.nuvation.com

Re: Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

[Stephen Munnings]

-----Original Message-----
From: Eric Nelson [mailto:eric.nelson@boundarydevices.com] 
Sent: Friday, June 20, 2014 5:19 PM
To: Stephen Munnings; Fabio Estevam; Otavio Salvador
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?

Hi Stephen,

On 06/20/2014 12:31 PM, Stephen Munnings wrote:
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Friday, June 20, 2014 2:17 PM
> To: Otavio Salvador
> Cc: Stephen Munnings; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Does anybody know of a quick way to migrate an IMX6 BSP from dora to daisy?
> 
> On Fri, Jun 20, 2014 at 2:18 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
>> During the change, we (U-Boot community) ported all boards in the 
>> source code but as you keep your board in an internal fork you need 
>> to handle it yourself.
> 
> Tha's correct. In order to avoid such pain in the future, Stephen could add his board support to mainline U-boot.
> 
> This way, whenever an API change happens, the board will be automatically converted.
> -----End Original Message-----
> 
> 
> Thanks Fabio and Otavio.
> 
> Even if we were going to put this board in the mainline U-boot 
> (somewhat unlikely, as the board itself is a sub-component of a larger 
> system, and not likely to ever hit the market as the "board by 
> itself"), it was (and still is) under development. I don't think it is 
> very wise (if it is even allowed) to put an unfinished board into the U-boot mainline.
>
> The only issues I have here are:
>
> a) The lack of notification that such a change had happened between 
> dora and daisy. And I don’t see how I can blame anybody for that, as I  
> am not sure how that information should/would/could have been sent to 
> the right target audience in the appropriate time frame(s) anyway.
> Timely responses to my query (which did happen) are sufficient, I think.
>
> b) The lack of the "conversion tool". Apparently Eric Nelson of 
> Boundary Devices did much of this work (thanks Eric <genuine> ), but 
> the conversion tool seems to have "gone missing". That would have 
> solved everything in a reasonably cost effective manner. A pity it is MIA!
> 

This script was kind of a glorified search and replace, and if you're just updating one board, doing this by hand is tedious but not very time consuming.

> For now, we will just stay with dora, and 2013.10. At least we will 
> now know some of the costs associated with moving forward if we ever 
> need to.
> 

I do think you're missing something. The pad changes I made were to U-Boot, and there's no reason you can't stick with your 2013.10 version of U-Boot and migrate to a 3.10.17 kernel.

Changing the kernel is likely much more involved, since you should switch to device-tree in the process, and no amount of tool helps there.

Your best bet is to closely track your differences from another board that's already made the jump.

This is essentially what we do with our 20-some-odd custom boards that tend to be variants of SABRE Lite/Nitrogen6x designs.

Regards,


Eric

-----End Original Message-----

Hi Eric,

I figured the script was just something like a sed script.

In our case, the best course of action would simply be to stick with the dora branch.
That is what we started with, and that seems to work.
Then we don’t have to worry about Uboot changes, nor yet Linux kernel changes.

The problem of updating (even one board) is that doing it by hand is tedious, is more error prone, and IS somewhat time consuming.
Oh, it is only measured in single digit days of effort (1 to 3, I would estimate), but at current engineering rates, that is expensive.
If we had multiple boards, it could be amortized across the group of boards (as you seem to have done).

We do already track differences from a particular board (the wandboard solo).
But with different circuit layout and pin muxing, we re-did all the muxing (using the Freescale tools) and this just happens to be the code that got hit. 

I have looked up your company, and see that your company is somewhat similar to ours.
One difference, however, is that you develop your own products, and specialize somewhat in this area.

We do custom design work for clients, from concept to manufacturing, and handle a wide spectrum of diverse projects using all kinds of different vendors' products.
We have even had some clients that ask us to "try and think of ways certain things can even be done".
In this case, we are doing a custom design for a client that only has this one board that uses the IMX6.

I really don't want to create a "tempest in a teapot", but without the conversion utility, our best bet overall really seems to be to just stick with dora and all that implies.

I wanted to try to move to daisy, but we knew it was an experiment with no implied guarantee of success.
Staying with dora is not an odious option, we can easily live with it.

Thanks for all the time you have spent discussing this issue.

Regards,

-- 
Stephen Munnings 
Sr. Design Engineer | 519.594.0976 
www.nuvation.com