RANT Alert: Why, oh, why did Freescale go and change all the pin names in the

[Symbolic]

Why, oh, why did Freescale go and change all the pin names in the #include files for the IMX6 processors?  (At least keep the old names for compatibility)

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

Over and above that, they did not keep the old names for compatibility!!

What kind of bush league move is that!?!?  :smileyshocked:

Does somebody at least have a utility that I can run the source code through to convert all the old names to the new names??

I am estimating 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).

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)

Either of these alternatives just uses too much time (costly time).

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.

Either of these alternatives just uses too much time (costly time).

SO....

I feel that I have been forced to go back to the dora branch and stick with that.

I guess the upgrade path from dora to daisy is not all that easy in real life!!

[igorpadykov]

Hi Stephen

I believe most appropriate to sent these comments

to people who writing yocto.

Please post this to meta-fsl-arm mailing list, so that someone could try to assist you.

https://lists.yoctoproject.org/listinfo/meta-freescale

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[Symbolic]

Ummm, why would it be most appropriate to send these comments to the yocto people?  :smileyconfused:

Are they responsible for maintaining the Freescale imx6 *.h files for the Uboot releases?

(<uboot>/arch/arm/include/asm/arch-mx6/*.h)

I guess it is possible, but it doesn't seem likely.

While the problem manifests as a big issues when migrating a BSP from dora to daisy, the problem is not in the migration itself (even though it may seem so in my comments).

The problem is that the Uboot include files (*.h) have changed all the pin PAD names so that the real problem is in migrating from Uboot 2013.10 to Uboot 2014.01.

Also, it is not that I need help (unless somebody has a utility to run my source code through to change all these names automatically).

I am perfectly capable (in this case) of doing the work needed.

Unfortunately, it is far too much work, so will not get done.

Unless, of course, somebody has a quick solution of some kind.

(that might be in the area of addressing comments to the meta-freescale mailing list)

[RandyKrakora]

Do the new pin names match the RM more closely? Maybe that's why it was done?

For the names that changed, why not just define all the old PAD names to the new ones and include that header? If you do this and post the patch for it, maybe it will help others?

-RK

[Symbolic]

Hi Randall,

  Thanks for the answer.

  The bottom line is that all that takes time (and that costs money).

  Sure, the new names might match the RM more closely (a good thing).

  If so, though, the old names should have been kept (or optionally defined) so as to not break compatibility with already existing code.

  Those who did it, though, were in a better position to make the appropriate aids available (especially as they were causing others the pain with the changes).

  Yes, if I did spend the money to create the new header (and it is far from "just define"), I would make it available to others.

  I am not likely to do that, however, as it is far easier and cheaper to simply stay with Uboot 2013.10 and - by extension - the dora branch.

  It is just that this would be an additional cost if I ever had to migrate to daisy, or beyond, in the future.

  And, really, so unnecessary if some basic, simple precautions had been taken.

[EricNelson · Accepted solution]

Hi Steve,

There are two parts to this: U-Boot and Linux, and they have somewhat different answers, but the key to both is that the pad name declarations were originally defined separately for the two sub-architectures of i.MX6Dual/Quad and i.MX6Dual-Lite/Solo, through separate header files.

The trouble is that the names for common pad registers were different, even when the functions were exactly the same.

Nobody caught this in the early Freescale releases because Freescale wasn't shipping boards with options of different processors.

This was caught and fixed in the process of getting i.MX6 support into the main-line Linux kernel, which made it possible to have a single board file (Device Tree) to support either processor variant. In the process, the names were also cleaned up quite a bit. In the latest kernels from Freescale, these pad names are present, and in fact, the board*.c files should normally go away (requiring lots of effort on your part).

As far as U-Boot goes, I'm to blame. We've been shipping boards with options for the different processors for a long time, and we submitted patches to main-line U-Boot to consolidate the pad names, and used the pad names defined in the Linux kernel in the process.

     [U-Boot] [PATCH 0/2] i.MX6 (DQ/DLS): use macros for mux and pad declarations

In the process, we updated the code for all boards that were in main-line U-Boot. We also had (past tense) a tool for doing this, but don't seem to have a copy any longer.

I'm sorry that this caused you grief, but you did gain a feature in the process. You should be able to use your boards with the other processor types (if that's desired) with little code change.

If you want to participate in these processes, you should subscribe to the relevant mailing lists (linux-arm-kernel, u-boot).

BTW, you can use 'git log' or 'git blame' to put names to the guilty parties.

Regards,

Eric Nelson

Boundary Devices

[Symbolic]

Hi Eric,

Thanks for your reply.

I understand what happened.

And it does happen from time to time.

I have subscribed to the mailing lists in the past, but it just chews up too much time to try and keep current on everything.

(I work on a broad range of things, not restricted to Linux and UBoot, or even software)

I was not aware of this potential issue, till I ran into it - head on.

Our board file was not in the UBoot main-line (and therefore you could not convert it for us) for two reasons:

a) It is/was still under development

b) It is part of a commercial product, and we have not gone through the process (and are unlikely to) of pushing this board back to UBoot - partly because nobody else would be using this board (aside from our customer) , and partly because they might have qualms about releasing this information to the "wild" (the board.c file can tell an informed reader a considerable amount about the product)

The only real remaining problem here is that the conversion tool is not available.

It would also have been nice to have some notification of this problem, but I understand that it might be difficult to figure out how, to whom, and when to make this information known.

Thanks again.

[OtavioSalvador]

Well I am sure you contacted your legal department about the GPLv2 implications and how to achieve compliance. In any case be sure to have the code ready to share for customers as this is required by GPL and using the mainline or not does not change it.

[Symbolic]

Hi Otavio,

  Yeah, the legal aspects of this are always of some concern.

  I, personally, have no problem with the open source idea, nor of contributing to it.

  In fact, the worst drawback of that (from my own personal perspective) is the fear of criticism of all the "poor code" and "poor adherence to standard coding conventions".

  I happen to hold somewhat contrary views to the official "linux kernel coding standards".

  (I think there is not enough white space for best readability and maintainability in it - i.e. it is too compact, an outdated virtue IMHO)

  I don't want to start a debate about it, though - each to their own as long as it is reasonably readable.

I am certain that we will be advising our customer (who will own the system and get copies of the code we have developed) about their legal responsibilities under GPLv2 to their customers in turn.

I don't think that they are concerned about the code becoming public after the product hits the market.

I think (not an official or even particularly informed opinion BTW) that they might be more concerned with it being a "before the introduction of the product" information leak.

I also don't think that very many of their customers would even recognize that Uboot and embedded Linux was even being used in the product.

But, if they do, and care, I expect that they would happily be given all the source code that they request and are legally entitled to.

This would not include the application running on the system, of course.

On another note:

  I have seen a lot of the work, and the quality and quantity of the work you have contributed to this community.

  I am impressed and grateful.

  Thank you!

[OtavioSalvador]

Stephen,

Thanks for your words. It is quite important to me to know people do see value in the work I do.

Thanks again.