I am porting u-boot from the NXP SDK for the ls1021ATWR to our custom board.
I intend to use the GPIO lines to turn on/off LEDs for diagnostics and use GPIO lines for other various purposes.
I saw a posting and responses from May 18 & 19 regarding the unimplemented GPIO functionality in u-boot for the twr board. A patch was provided to add the functionality.
I tried the patch and it does not work for me. Some of the patches installed, but some did not. Specifically, one for the makefile did not, so I added the one line manually.
When I tried to build u-boot, it failed because it could not find "GPIO_BASE_ADDR"
I did a grep "grep -r GPIO_BASE_ADDR *" from the u-boot git directory. No such constant was found for this architecture.
I also searched for that text in the patch file. It is not there.
Below is the header for the referenced patch file.
diff -urN orig/board/freescale/ls1021atwr/ls1021atwr.c new/board/freescale/ls1021atwr/ls1021atwr.c
--- orig/board/freescale/ls1021atwr/ls1021atwr.c 2017-05-19 16:17:59.724741823 +0200
+++ new/board/freescale/ls1021atwr/ls1021atwr.c 2017-05-19 16:48:37.537989631 +0200
So, I have a request and a question:
Request: Could you be so kind as to supply a patch for the current revision of the ls1021atwr board which provides GPIO functionality in u-boot please.
Question: Was the patch supplied ever tried as I see no way it could have worked unless it was due to a possible revision difference.
Thank you in advance
I just want to say thank you to Yiping Wang of NXP for supplying a patch to make this u-boot GPIO happen.
The patch files was never tested (by me), it looks like that you are the first one. The original changes were made by me in a local copy of the U-Boot repository and I only made the patch file when someone asked if someone had U-Boot LS102xa GPIO implementation. I did that quickly and without testing the patch file itself. I have the updated the patch file I posted before, so you can download it and check if it is now complete.
The patch files is missing a patch for the file "arch/arm/include/asm/arch-ls102xa/config.h", You have to add the following line to "arch/arm/include/asm/arch-ls102xa/config.h":
#define GPIO_BASE_ADDR (CONFIG_SYS_IMMR + 0x01300000)
Take into account that you have to add some configuration defines to the board config file (e.g.: "include/configs/ls1021atwr.h") too. For example:
/* GPIO */
#define LS102XA_GPIO_CTRLRS 1
/* Unused GPIOs are programmed as active outputs with data 0 */
#define CONFIG_LS102XA_GPIO_1_INIT_DIRECTION 0xffffffff
#define CONFIG_LS102XA_GPIO_1_INIT_OPEN_DRAIN 0x00000000
#define CONFIG_LS102XA_GPIO_1_INIT_VALUE 0x00000000
Thank you Kees,
However; When I asked my manager if I could do this board with open source u-boot/Linux instead of this SDK, he said he wanted to use the SDK to minimize risk due to the fact that the SDK is supported by NXP and that if we used open source, then we were "on our own."
While I am greatly appreciative of your response and the information you provided, I find it unsatisfactory for the following reasons:
1. You never tested the patch the first time it was posted, yet it was posted.
2. You never tested the original patch and thus it was missing items and could have never worked, thus costing me DAYS of progress because I did as the NXP community web site requests and prior to asking for help, checked for previous discussions. That is where I found the incomplete and untested patch. Then, after trying it and having it fail, I had to submit the question and wait 2 days for an answer that once again is untested.
To me, this is not support above what can be obtained from the open source community, since we are in the end "on our own" anyway. GPIO is an integral part of u-boot.
So, I have one more question:
Question: Your reply stated "I have the updated the patch file I posted before, so you can download it and check if it is now complete.
The patch files is missing a patch for the file "arch/arm/include/asm/arch-ls102xa/config.h", You have to add the following line to "arch/arm/include/asm/arch-ls102xa/config.h":"
So, my question is this: Is the patch you supplied in your response complete, but untested or do I have to modify it further, as your comment is confusing?
I posted the patch file because someone else asked if an U-Boot LS102XA GPIO implementation was available and I just developed it. I wanted to share it so that the (NXP) community could benefit from it. Yes I did not test it because it would cost me too much time and I do get paid by the community.
Your boss is paying you for being able to use the GPIOs of the LS102XA. So it is your responsibility to do that in the most efficient way. You could have developed it by yourself (just like me) or asked NXP to do it for you (and pay for it if do not have support contract that covers it). However you decided to use something from the community. You should have known that anything taken from an community (of volunteers comes) with no warranty. Anyhow I think my patch file is a good start and the person who asked for it in the first place was happy with it.
I think the community appreciate you effort of testing my patch file because it have improved the quality of it. That is what a community is; a group of people that wants to help each other. Getting free help you do not get by complaining but by thanking and providing constructive feedback.
The answer of your last question is that the patch file is not tested for completeness. If it is still not complete you can give me feedback op update it by yourself.
I was under a misconception. I thought this "community" consisted of NXP engineers answering questions officially.
You see, our Avenet customer service engineer led me to believe that with statements made.
I understand now and apologize due to the misinformation.
Yes indeed, I am being paid to be able to use the GPIOs of the LS102XA if it is not supplied, however; I am also being paid to do the job quickly and we have boards arriving any day now. Thus it is imperative that I apply my expertise in a judicial manner and not reinvent the wheel when it is already available.
So, once again, I apologize and understand now that we were misled by our Avnet cust. svc. engineer. They told us to pose the questions to the community and them simultaneously. They said that if we do that, they will see that it is given a priority. As, such, that and other statements led me to believe that the community was FORMAL support from NXP.