u-boot support for pins

[Tracy Smith]

The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18),

1. Did I miss the names for these pins in u-boot?

2. If u-boot does not support these pins, should they be added to u-boot, and/or added to the kernel to support these pins?

Need these pins to support USB/CAN device on a custom BBB. Need to pinmux these for the USB/CAN from Lawicel.

thx,
Tracy

[Tracy Smith]

An update.   In u-boot/board/ti/am335x I do see the following. So, the pad name for I2C_DATA is uart1_ctsn for D18.  For pad name uart1_rtsn it is pin D17.  So this will give the DCAN0_TX/RX for u-boot.

static struct module_pin_mux i2c2_pin_mux[] = {
        {OFFSET(uart1_ctsn), (MODE(3) | RXACTIVE |
                        PULLUP_EN | PULLUDEN | SLEWCTRL)},      /* I2C_DATA */
        {OFFSET(uart1_rtsn), (MODE(3) | RXACTIVE |
                        PULLUP_EN | PULLUDEN | SLEWCTRL)},      /* I2C_SCLK */
        {-1},
};

Now looking in u-boot/board/ti/am335x for E17/E18 for DCAN1_TX/RX.  One could use E17/E18 for CAN1 instead of the P9 expansion header.

[William Hermans]

SO what is it that you're trying to do ? I've read your posts, but am still mystified. Just sayin' . . . I've been working with this hardware for around 5 years now,  have written many device tree overlays for various hardware configurations. Including GPIO, I2C, UART, CAN, SPI, etc.

I'm willing to give you some guidance, but need to understand what it is you're trying to do . . .

I2C really isn't that hard to get working. Nor is most of it.

[Tracy Smith]

Hi William,

Using the TI pinmux tool it provides two pins associated with CAN1. One for TX and one for RX.  I just need to use these two pins for the uboot overlays instead of the I2C P9 extension header supported by the most recent kernel releases. On our custom BBB we don’t have a P9 and instead we use test point pins for CAN1. CAN0 is no longer a concern since I have the pad names associated with the pins I need.

I need to know the pad name or how to create the pad names for these two pins the pinmux tool associates with CAN1, so I can use these for the u-boot pinmux and the kernel device tree.  I agree this is not difficult when you have the pad names and the pins available. Simply copy, paste, and modify the dts and pinmux file as needed.

Thx, Tracy

Sent from my iPad

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrdO87s1J7uKrJ%2BEvRKQRmKhahZBq%3DmtK1ktk4sChsbkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

---------- Forwarded message ----------
From: William Hermans <yyr...@gmail.com>
Date: Wed, Nov 1, 2017 at 9:58 AM
Subject: Re: [beagleboard] Re: u-boot support for pins
To: Tracy Smith <tlsmi...@gmail.com>

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-CAN1-00A0.dts

Pad name is on the beaglebone schematic. Which for the purpose of using overlays is useless.

On Wed, Nov 1, 2017 at 5:44 AM, Tracy Smith <tlsmi...@gmail.com> wrote:

Hi William,

Thanks for the email and here is what I’m trying to do.

The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver.

 

On the MachineKit Debian Beagle the CANUSB is a dev/ttyUSB0 device.

On our custom BeagleBone Black, we want both CAN0 and CAN1 accessible USB devices.  We don’t want to have to add a P9 expansion header on the custom board for I2C and we have specific pins E17 and E18 we want to use that are designated as possible CAN1 pins on the BeagleBone Black schematic. 

These two pins for CAN1 are tstpt1 pin E17 and TP9 pin E18.  Just need to see if there is a pad name associated with these pins so I can use them for the pinmux file and device tree to make CAN1 available as a USB device for uboot and the kernel.  This is what I need.

Looking through the pinmux files for any pad names associated with these two pins.  

Thx, Tracy

On Oct 31, 2017, at 7:55 PM, William Hermans <yyr...@gmail.com> wrote:

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.

[William Hermans]

On Wed, Nov 1, 2017 at 5:44 AM, Tracy Smith <tlsmi...@gmail.com> wrote:

Hi William,

Thanks for the email and here is what I’m trying to do.

The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver.

 

On the MachineKit Debian Beagle the CANUSB is a dev/ttyUSB0 device.

On our custom BeagleBone Black, we want both CAN0 and CAN1 accessible USB devices.  We don’t want to have to add a P9 expansion header on the custom board for I2C and we have specific pins E17 and E18 we want to use that are designated as possible CAN1 pins on the BeagleBone Black schematic. 

These two pins for CAN1 are tstpt1 pin E17 and TP9 pin E18.  Just need to see if there is a pad name associated with these pins so I can use them for the pinmux file and device tree to make CAN1 available as a USB device for uboot and the kernel.  This is what I need.

Looking through the pinmux files for any pad names associated with these two pins.  

Thx, Tracy

Just use the file I sent you, no worries about anything. If you NEED to put it all into one large overlay file, you can pretty much just copy paste what's in that file into your existing overlay. WIth some caveats of course. You'll need to make sure the file is organized correctly. 

Personally, I'd just leave the file as is, and load it standalone.

[Tracy Smith]

We have no P9expansion header.  I’ve already discussed this with Robert Nelson.  We are using the AM3358 pins I sent previously.  Any can using the P9and this overlay will not work for our custom board.

Sent from my iPad

[William Hermans]

On Wed, Nov 1, 2017 at 10:02 AM, Tracy Smith <tlsmi...@gmail.com> wrote:

Hi William,

These overlays from Robert Nelson are associated with the P9 expansion header.  We don’t have a P9 expansion header on the custom BBB we are using. So we can’t use this overlay.

Thx, Tracy

You're not making any sense. Just because you can mux pins, doesn't mean you can also reassign pins to something they're not intended.

[Robert Nelson]

On Wed, Nov 1, 2017 at 12:05 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
> We have no P9expansion header. I’ve already discussed this with Robert
> Nelson. We are using the AM3358 pins I sent previously. Any can using the
> P9and this overlay will not work for our custom board.

Ah, i should just ignore you then, for some reason i keep thinking you
have a BeagleBone Black..

So route the pins you need, implement all the pimux's in u-boot and
the base dtb's..

You have no reason to use overlays at all..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

On Wed, Nov 1, 2017 at 10:12 AM, William Hermans <yyr...@gmail.com> wrote:

On Wed, Nov 1, 2017 at 10:05 AM, Tracy Smith <tlsmi...@gmail.com> wrote:

We have no P9expansion header.  I’ve already discussed this with Robert Nelson.  We are using the AM3358 pins I sent previously.  Any can using the P9and this overlay will not work for our custom board.

Ok, good, that doesn't make a bit of difference at all. Those pin names in the overlay are just variables used by the file, and initially by cape manager. cape manager translates those variable names into addresses when the overlay file is compiled.

Passed that, the software that is provided could stll use the Px header designation for the pins, and it'll still work fine if you're using something like universal IO + config-pin, so long as you all have not done something drastically different in your layout. I do recall that some devices can be done using multiple pin configurations, and one in fact is still like that with the beaglebone design as is.

Anyway, I do not remember if CAN1 has the potential to be on different pins or not. Out of the processor. But working with the file I sent you a link to all that can easily be changed.

Well technically, I'm not 100% positive on this. There could be hooks, etc I'm not aware of, and I have not done this hands on personally. But so long as you're using the same pins the bealgebone is using. It should work.

Are you, or are you not using he same pins as the beaglebone for CAN1 ?

[William Hermans]

Another thing I did not consider is that it sounds like you could be using a completely different board file overlay for your hardware, at which point all bets are off.

[William Hermans]

On Wed, Nov 1, 2017 at 11:01 AM, Tracy Smith <tlsmi...@gmail.com> wrote:

Ok look this custom board is based on the BeagleBone Black. For all intense and purposes it is the BBB. The pins for the AM3358 are the same. The primary difference is no P9 expansion header. What you are suggesting below is exactly what I’m doing and why I have the questions I do because your CAN support will not work on our custom BeagleBone Black.

Customers will use the BBB as a reference platform and will actually have to do pinmuxing. When I do mention custom board, you do ignore me. But you shouldn’t because not all companies that use the BBB as a reference platform will use the P9 expansion and they will want to have CAN support in the kernel even without the P9 expansion header. You don’t have to use the P9 and the overlay being used to support CAN0 and CAN1

You seem to be limiting CAN support to those using the P9 expansion header?  Why is that? Does it allow for four or more CANS?  

Really appreciate the assistance and it has been and continues to be extremely helpful. 

What limitations or constraints are causing you to have to use the P9 expansion header for CAN?  Knowing this help justify adding an expansion header to the design. 

I need to look closer at the overlay. But knowing these constraints could justify adding the P9 expansion header to our custom BBB board.

Thx, Tracy

First, I am not affiliated with beagleboard.org, cicuitco or any other organization related directly to the beaglebone, or beagleboard products. Or anyone who sells said products. I am just your average community member, whose been using the beaglebone products since it's release date

Second, I never said I was ignoring anyone.

Third, you're delving into territory that myself, and most others have not gone into. So if someone does say they're ignoring you, it could very well be that they have not done what you're doing, and do not want to give you incorrect information.

Lastly, be more verbose with your information. Just saying "wont work for us" doesn't tell us what the underlying problem is, or how to help you solve your issue.

So . .. tell us EXACTLY what you've done, and EXACTLY the errors your experiencing. Then perhaps, if you're verbose enough, someone on this list can help you.

[Tracy Smith]

E17 and E18 we want to use that are designated as possible CAN1 pins on the BeagleBone Black schematic. 

Not using a different overlay, using the existing 4.14 kernel and 2017 I boot that Robert Nelson suggests using for the BBB. But we need to pinmux for E17 and E18 because the TI pinmuxing tool finds no conflict with these two pins on our custom board. I’ll go back and check the CAN1 but prior to Roberts changes last week that did not use the P9 expansion header, the unit pinmux used different pins CAN1 I believe.  With the P9 expansion header, can’t use Roberts overlay because there is no P9 expansion header on our BBB board. I’ll go back look at the pins for CAN1 prior to then P9 overlay changes from last week by Robert.

This is just basic pinmuxing.  And looking for E17 and E18 pons since these are supposed to support CAN1 on the AM33xx.

Thx

Sent from my iPhone

[Robert Nelson]

On Wed, Nov 1, 2017 at 1:14 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
> E17 and E18 we want to use that are designated as possible CAN1 pins on the
> BeagleBone Black schematic.
>
> Not using a different overlay, using the existing 4.14 kernel and 2017 I
> boot that Robert Nelson suggests using for the BBB. But we need to pinmux
> for E17 and E18 because the TI pinmuxing tool finds no conflict with these
> two pins on our custom board. I’ll go back and check the CAN1 but prior to
> Roberts changes last week that did not use the P9 expansion header, the unit
> pinmux used different pins CAN1 I believe. With the P9 expansion header,
> can’t use Roberts overlay because there is no P9 expansion header on our BBB
> board. I’ll go back look at the pins for CAN1 prior to then P9 overlay
> changes from last week by Robert.

What i suggested, assumed you were using a BBB. Thus since you have a
custom board, it's all null and void..

Use TI's pinmux tool and properly route your can signals.

[Tracy Smith]

These comments were a reply to Robert,!but threads are getting confused a bit for everyone especially for me.

Let me look at this more and see if I can find the pinmux pins I need in i-boot and the kernel. Even if they don’t exist in u-boot, they should in the kernel. Then I can do as Robert indicates, change the pinmux U-Boot file and dts.

If I go into any more detail, it’s going to take too much time and I’m already behind on this.  Robert understands the concerns and what I need. I simply need to pinmux pins E18 and E19.

[Tracy Smith]

The signals are all routed just need to pinmux E18 and E19 which are the same for the BBB.

Sent from my iPhone

[Tracy Smith]

The need to use E18 and E19 For CAN1 comes from the TI pinmux tool.

Sent from my iPhone

> On Nov 1, 2017, at 1:19 PM, Robert Nelson <robert...@gmail.com> wrote:
>

[William Hermans]

What Robert said, but in addition, it might be handy if you let us know what hardware( everything ) you're using to help us, help you spot potential hardware conflicts. I've worked on a project that did in fact use one CAN interface a couple or three years ago. It works, but I only used one bus. Not two. Additionally, I was using an older kernel, so I've not the same on a current kernel. At some point I think I did test a semi recent kernel, just to get the interface up and running, but I did not test the C code I wrote a while back on that interface.

So how do you know it's not working. Just saying it doesn't work does not give us the steps you taken to get where you are. or the error messages you're getting, that could help us troubleshoot your issue for you. Nor does it tell us if the driver for a given CAN interface is even loaded. You see where I'm going ? There are many places for this process to go wrong.

[Robert Nelson]

On Wed, Nov 1, 2017 at 1:24 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
> The need to use E18 and E19 For CAN1 comes from the TI pinmux tool.

Umm, on the ZCZ package used on the BBB

E18: dcan1_tx
E19: not available for can0/can1...

Want to try again?

[Robert Nelson]

On Wed, Nov 1, 2017 at 1:28 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Wed, Nov 1, 2017 at 1:24 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
>> The need to use E18 and E19 For CAN1 comes from the TI pinmux tool.
>
> Umm, on the ZCZ package used on the BBB
>
> E18: dcan1_tx
> E19: not available for can0/can1...
>
> Want to try again?

Ps, random "ti pinmux questions" should go to:

https://e2e.ti.com/

Specially when you have random hardware..

This is the Beagle Community. We don't get paid for support..

[William Hermans]

On Wed, Nov 1, 2017 at 11:28 AM, Robert Nelson <robert...@gmail.com> wrote:

On Wed, Nov 1, 2017 at 1:24 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
> The need to use E18 and E19 For CAN1 comes from the TI pinmux tool.

Umm, on the ZCZ package used on the BBB

E18: dcan1_tx
E19: not available for can0/can1...

Want to try again?

Yeah tx, and rx are staggered two pins apart in the pdf file I have here. what are the Px header assignments, or gpioxx_yy nomenclature assignments ?

[Tracy Smith]

Agreed. And the pins are E18 and E17 for DCAN1_RX/TX on the BBB schematic. These are the pins the TI pinmux tools says use. So, trying to use these two pins for CAN1 because we don’t have the P9 expansion header. 

That is just the first step in this CAN bring up process for a custom BBB board that doesn’t have a P9 expansion header.  So I agree.

I still have a question for Robert, why is the P9 expansion header being used for then CAN on the most recent release instead of the AM335X CAN0 and CAN1 RX/TX pins D17/D18 and E17/E18?

Thx, Tracy

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpKGh0pYiYL5AjJuDUXqLHTwunYGS_uCaYHXqwkz4xBMg%40mail.gmail.com.