u-boot support for pins

GoogleGroups
1

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

2

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.

3

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.

4

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

5

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.

6

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.

7

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.

8

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.

9

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,

10

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 ?

11

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.

12

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.

13

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

14

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.

Regards,

15

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.

16

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

17

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

18

Umm, on the ZCZ package used on the BBB

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

Want to try again?

Regards,

19

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.

20

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

Regards,