Where is pin mux setup for Spectrum Digital C6A816x-evm in u-boot?

Ah, I did miss something ... my grep didn't include .S files :(

I see now how pin mux gets setup of for things like NOR ... arch/arm/cpu/arm-cortexa8/ti81xx/lowlevel_init.S uses the neumonics I mentioned above (GPMC_A12 etc.) that are defined arch-ti81xx/in cpu.h

BUT ... the 816x still doesn't appear to follow the convention used on other TI processors where the pin mux for other things are setup with the MUX_VAL macro. 

If the ti816x is using the MUX_VAL macro to setup pin mux ... then I sure don't see how it is doing it.

If I'm wrong ... someone please show me the way :)

Regards,

Brian

Hi Brian,

In DM8168 u-boot, pin-mux is done only for NOR boot. When DM8168 comes out of reset, only 12 GPMC address lines (a0 - a11) are available. Because of this, only 4KiB of NOR is visible. Hence we need to do pin-muxing when u-boot comes-up and this has to be done from the initial 4KiB code. We might also have to re-configure GPMC for the new NOR size. All this have to be done from the initial 4KiB of u-boot image. Once this is done, the whole of NOR will be visible.

We wanted this piece of code to be less dependent on other u-boot modules, hence we did not use pin mux macros (It should also fit in 4KiB)

The same information is available @ http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_PSP_U-Boot#NOR_Support

Regards

Mansoor

Hi Mansoor,

Thanks for your prompt reply.  I pretty much figured out how the pin mux for GPMC_A12 - 27 was being setup (after I included .S files in my grep ;) )

I understand what is going on for NOR support in that document you mentioned.  Our custom board that I'm in the process of bringing up has two NOR flash parts and a whole bunch of stuff hanging off of it ... so we have to provide pin mux setup as most of the way the board is strapped does not match the default pin mux functions.

Where I was thrown off was I expected to see a mux.h file and another header file that used the MUX_VAL macros to setup the pin mux even if it is all defaults (at least it gives someone a starting point ... I don't think I want to add all I have to do in the assembler file lowlevel_init.S!).  From what I've seen, c6a816x u-boot code is the first to deviate from this established pattern which kind of goes against the concept of "least astonishment" http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Further, the TI pin mux utility generates a mux.h and a pinmux.h with MUX_VAL entries to setup the pin mux so I guess what I'm getting at is it is odd to NOT see these files especially in a EVM which is intended to be a baseline for development.  The EVM is an example of "what right looks like" if you will.

Folks that have not worked with u-boot on other modern TI processors and don't know about the TI Pin Mux Utility will probably be kind of at a loss when they try to setup the pin mux on their custom board when no example of how to do it exists on the 816x EVM.

I learned most of what I mentioned above working on OMAP 3530 and DM37xx and some others.

Regards,

Brian

Hi Brian,

Is it possible to share more information about your EVM? How are the NORs connected to GPMC and pin-mux details?

The lowlevel_init.S pin-mux is required only for NOR boot, we don't recommend using it for configuring all pin-muxes. Also, we always try not to include things which are not for TI EVM so that user is not confused by the unwanted stuff (least astonishment). C6A816x and C6A814x NOR boot is different from OMAP3 or DM37xx devices hence I don't see any deviation from established pattern. If there was any, we would have used it in first-place.

We could consider giving some information in the documents related to pin-mux which will help people who are new to u-boot / pin-mux.

If you have a patch which does NOR boot pin-mux with least-astonishment, we could consider including that patch. Also, can't you have the pin-muxing in Linux, any specific reason to have it in u-boot (if not related to booting)?

Regards

Mansoor

OK, you got me.  I mis-spoke about the 814x ... it does have a mux.h file but does not use the MUX_VAL macro.

AM3517, beagle, sdp3430, zoom1 & zoom2 and others do use it though.  It is a core omap3 ... cortex A8 method was my point.  And you do have documentation on pin mux ... http://processors.wiki.ti.com/index.php/Pin_Mux_Utility_for_ARM_MPU_Processors ... it even comes with the 816x ez-sdk etc.  All I'm saying is 816x should include examples (a starting point if you will) that follows the established (and documented) convention for doing pin mux.   I'm just pointing out an apparent disconnect between the guys writing the pin mux utility in which its documentation clearly says it covers the AM35xx, AM37xx/DM37xx, AM389x/CA816x/DM816x and OMAP35xx and the actual u-boot code delivered in the ez-sdk of 816x & 814x.

Now that I look at it closer, 814x looks like it is going off in a tangent too ... I looked at the mux.h that was there and didn't even recognize it.

Regards,

Brian

Hi Brian,

The NOR boot in DM816x and DM814x has a limitation, during power ON  we can access only 4KiB of NOR because GPMC address lines A12 to A25 are muxed. Hence we did not use the MUX_VAL macros for setting up pin-mux for NOR boot. We cannot setup the GPMC pin-mux while running from NOR (XIP) and hence the pin-mux code should run from OCMC. Also this tiny piece of code has to fit in first 4KiB of u-boot. Because of these limitations, we ended using assembly for NOR boot pin-mux

Apart from NOR boot, we should be able to use the pin mux utility for other modules. We will investigate DM816x and DM814x u-boot package on this front and will keep this thread posted of our progress. Thanks for your feedback.

Regards

Mansoor

I understand what is going on in lowlevel_init.S and why it has to happen the way it is being done.  Don't have a problem with it.  I think you are missing my point.  There isn't anything wrong with what you guys did in lowlevel_init.S regarding the NOR .. I just mentioned NOR originally as I saw #defines for GPMC_A12 but couldn't find where they were used at first.  I'm mostly talking about all the pin mux stuff that typically gets done in u-boot before the kernel boots.

From what I've seen in the past ... u-boot usually does the heavy lifting of getting the processor setup and the kernel just rides what has been done by it.  Yes, the kernel can do pin mux but usually 99% has been done in the boot loader and the facility to change it in the kernel has typically been used to make minor tweaks.

This site has done a good job of documenting the things that are typically discussed in the chat channels/forums and is a summary of what the community best practices have been so far:

http://elinux.org/BeagleBoardPinMux#U-Boot

Regards,

Brian

Hi Brain,

In DM816X most of the pins do not need any pin-muxing and the reset value is ok for them. U-Boot should be doing only the essential things and not pin-muxing for all the pins. Kernel should take care of the rest . This approch will save the time in debugging pin-muxing related issues. 99% of pin-muxing should be done in the kernel and not in the bootloader. You can find the Pin muxing example for DM816X is present in U-Boot. set_muxconf_regs() in "board/ti/ti8168/evm.c" does pin-muxing for MMC/SD.

DM814X pin-muxing needs to be re-worked. Something new was tried but limitations were found and the current approach will most likely to be dropped.

Regards,

Deepu Raj

Hi Deepu,

"In DM816X most of the pins do not need any pin-muxing and the reset value is ok for them" - not in the design of my board :)  It has a LOT more stuff hanging off it than the EVM so the defaults couldn't be used.

I think pin muxing in u-boot grew mostly out of the fact that early on it was broke in the kernel.  When the kernel did have pin mux support, I always though the u-boot code was easier to modify and more straight forward than the kernel.

I guess I'm old school.  I like to keep firmware related stuff in u-boot and not make my OS have to know about all the variants of the hardware beyond the minimum it has to know.

So for me, there are other considerations bearing on the problem.  I'll give you a real world example.

Would you agree that the kernel has a far greater chance of being upgraded in the field (we are talking about a completed product here) than say u-boot?

If so, consider that the guy doing the kernel probably isn't as familiar with the hardware as the guy that did u-boot.

Now consider this product is on a pole or communication tower.  The only way you can do a field upgrade of the software is over its wireless stack which means the whole box has to run in order to talk to it.

Now if pin mux was mostly done in the kernel, when you did a field upgrade of the kernel, the probability that something could get changed with pin mux that would prevent the board from restarting is great which means the board wouldn't come up and you just lost control of it.  It may as well be bricked. Now at worst, you have to send a licensed tower climber to get your box.  Or at best, if you have a u-boot net console, you can visit the remote site and maybe get u-boot access at the shelter at the foot of the tower.

Granted, pin mux is easier in the kernel today than it used to be but one needs to be very careful in the partitioning.  Never mind the fact that Linus is upset about the /arch/arm tree growing out of control with too many variants he has too look at upstream which is where this pin mux kernel code would go but I'm sure you will become familiar with that once you try to push your changes upstream :)

I know how to continue with what I need to do.  All I was trying to do here is point out that 816x (and 814x) appears to be doing its own thing and not even following published TI methods that ironically came with the ez-sdk.

I'm done with this.  Do what you want.

Regards,

Brian