[meta-freescale] 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 at boundarydevices.com] 
Sent: Friday, June 20, 2014 5:19 PM
To: Stephen Munnings; Fabio Estevam; Otavio Salvador
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?

Hi Stephen,

On 06/20/2014 12:31 PM, Stephen Munnings wrote:
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Friday, June 20, 2014 2:17 PM
> To: Otavio Salvador
> Cc: Stephen Munnings; 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 Fri, Jun 20, 2014 at 2:18 PM, Otavio Salvador <otavio at 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