Beaglebone Pins Initial Values

I am trying to figure out what state the beaglebones pins start in. I have trawled through the board-am335xevm.c and can see that it is setting up certain pins in particular ways, but what about the pins that it doesn't do anything with? Are they left in a random state, or the state u-boot put them in (if it even sets them?) or maybe in the AM335x default datasheet configuration?

I know I could just measure them but I would rather a more accountable method.

Regards,

u-boot _can_ set the pins up, too.

If you look at the AM3359 datasheet, the balls characteristics table
will say what the ball reset state and modes are. Any pins not setup
by u-boot or the kernel should still be in that state.

-Andrew

Thank you for your response Andrew, I have now found the ball reset states for all the pins I am interested in. Just one more quick question though, does anyone know if when the pins are muxed and GPIO lines are initialised any of the values get set, same with the SPI lines - is there an easy way to find this out in the kernel, or are the lines untouched until I do something in userspace with them (assuming that the kernel muxes them and then has nothing else to do with it).

Regards,

I'm not sure I understand your question.

Do you mean: What is the initial output state of pins muxed to be
outputs?

-Andrew

Hi Andrew,

Kind of, I'll try to be a bit clearer.

If I have worked out the Ball Reset State, would the kernel change that
state upon initialisation of a subsystem, e.g. the GPIO or SPI systems.

So, to be blunt, if the Ball Reset State is 0 on a pin, then it gets
muxed into a different function on kernel boot, will it still be 0
regardless until I explicitly change it, or can certain subsystems set
specific states for the pins when initialised?

Thank you for your help so far.

Best Regards,
Jack

Ball Reset State is the state of the ball when the device is held in
reset.

Ball Reset Release State is the state of the ball after being released
from reset.

Reset Release Mode is the mode the ball will be in after being released
from reset (usually modes are 0 through 7 with 7 usually being GPIO
mode).

Once u-boot or the kernel start, they can change the mode, the
pull-up/down, and the input/output of any balls that support those
changes.

For example, the UART0 pins (ZCZ package balls E15, E16, E17, and E18)
out of reset are all going to be in mode 7 (GPIO) and set to high-z
with an internal pull-up. Obviously, when u-boot starts, in order to
put out RS232 data (the console you see on the mini-USB port through
the FTDI chip), u-boot first has to change these pins to be UART pins
(mode 0) and tell each to use the proper input/output ability before it
can use the pins as a UART. For pins that are outputs, the pin will be
driven which ever direction it is told, I believe u-boot and the kernel
can influence this, but the pin hardware most likely knows a default
state to use (for example for a UART-tx line, should it drive high or
low when there's no data?) if one isn't given.

This is what happens each time u-boot or the kernel set up a muxing.
Be it for SPI, I2C, UART, MMC, Ethernet, or any other functions.
All balls come out of reset in a specific state, most likely, it won't
be the state you actually want, so either u-boot or the kernel will
change it.

Does that help or answer your question?

-Andrew

Yes, that does help and it is what I expected, thank you for the well written explanation.

The issue I am trying to solve is to prove deterministically the state of the pins throughout the boot up until my application runs and I have control over how they are managed.

A bit of insight into my project is that I have an FPGA connected over SPI and some GPIO, when I come to running my program which communicates to the FPGA through spidev in userspace and mmapping GPIO, the FPGA SPI interface has been trashed due to the pin outputs from the beaglebone on boot. To solve the issue I have to run my beaglebone program to get the pins into the right state, stop the program, reset the FPGA, then run my program again and everything is well.

We're implementing a 'reset line' on the FPGA but I would feel a lot more confident if I could deterministically map the state of the pins throughout boot (and as such appease the FPGA engineer).

At the moment I have this flow diagram:

1) Ball Reset Release State (known from datasheet)
2) u-boot pin muxing state (doesn't effect the expansion header so don't really care)
3) kernel boot (_unknown_.. this is where expansion header pin muxing and subsystem intitialisation happens - possible change of states?)
4) application runs (in control of pin states)

So an example of what could be happening is that the SPI_SCLK line could come out of the Ball Reset Release State Low, then upon muxing and initialisation the SPI_SCLK line could go High, which the FPGA would take as the start a clock tick, then when I run my program the FPGA is a clock tick out and the interface is useless until we get back in sync. The issue is that I don't know if the SPI_SCLK line gets changed when the SPI subsystem is invoked...

Regards,
Jack.

Yes, that does help and it is what I expected, thank you for the well
written explanation.

The issue I am trying to solve is to prove deterministically the state
of the pins throughout the boot up until my application runs and I have
control over how they are managed.

Why not just recompile the kernel and change the board-file to have
platform data for the SPI bus you want to use?

A bit of insight into my project is that I have an FPGA connected over
SPI and some GPIO, when I come to running my program which communicates
to the FPGA through spidev in userspace and mmapping GPIO, the FPGA SPI
interface has been trashed due to the pin outputs from the beaglebone on
boot. To solve the issue I have to run my beaglebone program to get the
pins into the right state, stop the program, reset the FPGA, then run my
program again and everything is well.

Why not just write a kernel driver that includes a spi protocol driver
and some GPIO abilities? Then you don't need to use spidev or mmaped
GPIO. Plus, you can get real interrupts for your GPIO, if you care.

At the moment I have this flow diagram:

1) Ball Reset Release State (known from datasheet)
2) u-boot pin muxing state (doesn't effect the expansion header so don't
really care)
3) kernel boot (_unknown_.. this is where expansion header pin muxing
and subsystem intitialisation happens - possible change of states?)

Kernel also can disable portions of the chip that aren't used. If you
don't have platform data setup in the board-file (or dt), you're
possibly at risk that the SoC disables those peripherals. Doesn't
sound like what you're hitting, but something to be aware of.

4) application runs (in control of pin states)

So an example of what could be happening is that the SPI_SCLK line could
come out of the Ball Reset Release State Low, then upon muxing and
initialisation the SPI_SCLK line could go High, which the FPGA would
take as the start a clock tick, then when I run my program the FPGA is a
clock tick out and the interface is useless until we get back in sync.

Isn't this the whole point of a chip-select line?
The FPGA shouldn't care what goes on while it's chip-select isn't
asserted. Pull up your chip-select.

The issue is that I don't know if the SPI_SCLK line gets changed when
the SPI subsystem is invoked...

It may. But if you wrote a kernel driver, have it simply setup the I/O
how you want (possibly using platform data), then pull the reset on the
FPGA, wait for the FPGA to come ready, and then start talking. That's
how it's usually done (in my experience). Connect the FPGA reset to a
GPIO, then you can reset it at driver init or if your kernel driver
detects that things are going screwy.

-Andrew

do not walk around and cause lots of trouble–fixing the kernel .
setup a EN singal in your FPGA.
only EN enabled can any things happen.
EN can be one IO sequence or serveral IOs’ transient state, which you can control in user space. NO expense, indeed.
only if EN is unique, it works.

2012-07-27

Andrew,

Those are a set of fantastic points. The kernel driver is something that I'm working myself up to - I've only been programming Linux for the past 6 months and only recently graduated from an Embedded Systems Degree (12 Months), this is definitely my final goal and I am slowly working my way there.

The point you bring up with the chip select lines is very valid, the issue is (which would be solved with a kernel driver :wink: ) that I am using GPIO lines for chip selects as the custom FPGA (a legacy design being re-used) requires chip selects for reads and writes, the beaglebone spidev driver has no capability for gpio chip selects and I currently have 3 (up to 6 in the future) FPGA's connected to one board - which is currently 6 chip selects (3 read, 3 write) - while the beaglebone only has 3 'real' chip selects over 2 SPI Busses if I recall correctly.

This is why it's getting into a mess overall I think, it's hacked together a bit and relies on mix of different systems cobbled together. This may just be the final push I need to get my head down and learn how to design and code a kernel module!

I'm very appreciative of all your help and I apologize if I was a bit unclear at times!

Regards,
Jack.

The point you bring up with the chip select lines is very valid, the
issue is (which would be solved with a kernel driver :wink: ) that I am
using GPIO lines for chip selects as the custom FPGA (a legacy design
being re-used) requires chip selects for reads and writes, the
beaglebone spidev driver has no capability for gpio chip selects and I
currently have 3 (up to 6 in the future) FPGA's connected to one board -
which is currently 6 chip selects (3 read, 3 write) - while the
beaglebone only has 3 'real' chip selects over 2 SPI Busses if I recall
correctly.

2 SPI buses, each with 2 chip-selects. If the data sheet is to be
believed. I believe the silicon can support more, but they're not
balled out on the am33xx chips. Other TI ARM parts ball out more SPI
buses and chip selects, the am33xx is a bit stingy.

Just be careful when using gpio for chip selects outside, like this.
The GPIO subsystem and the SPI subsystem aren't connected, directly, and
even if you pull a GPIO line and then immediately issue a spi_async
write (in the kernel, or what ever the equivalent in spidev land is),
there's no hard time requirement that the SPI write goes out on the
wire right away, it can be buffered and spi bus actions can, under some
use cases, be reordered (ie: not always in fifo order).

So, if you're writing to one FPGA, then writing to another right away,
your GPIO chip selects may not match the data on the SPI bus. I'm sure
the kernel can be made to do what you want, but I'd advise some extra
care, especially if the SPI bus starts getting busy.

This is why it's getting into a mess overall I think, it's hacked
together a bit and relies on mix of different systems cobbled together.

That sounds like normal engineering :slight_smile:
It worked once, in the lab, while standing on one leg, running debug
code? Ship it! :slight_smile:

-Andrew

Interesting thank you for the input. I haven't seen that happen in my prototype which is doing roughly ~30k reads and ~100 writes but I will make sure to try and guard against it.

My adventure will be ongoing over the next week and I'm sure you'll see more of me on the list regarding writing kernel modules - if anyone knows of any good guides or pointers that would be much appreciated!

Best Regards,

Worth reading LDD [1] (it's a bit out dated, but most things are still
very relevant, just that the API has changed a little since 2.6.10) and
looking at the spike driver [2].

[1]:https://lwn.net/Kernel/LDD3/
[2]:http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62

-Andrew

> The point you bring up with the chip select lines is very valid, the
> issue is (which would be solved with a kernel driver :wink: ) that I am
> using GPIO lines for chip selects as the custom FPGA (a legacy design
> being re-used) requires chip selects for reads and writes, the
> beaglebone spidev driver has no capability for gpio chip selects and I
> currently have 3 (up to 6 in the future) FPGA's connected to one board -
> which is currently 6 chip selects (3 read, 3 write) - while the
> beaglebone only has 3 'real' chip selects over 2 SPI Busses if I recall
> correctly.

2 SPI buses, each with 2 chip-selects. If the data sheet is to be
believed. I believe the silicon can support more, but they're not
balled out on the am33xx chips. Other TI ARM parts ball out more SPI
buses and chip selects, the am33xx is a bit stingy.

Other parts with McSPI have greater than 2 chip selects per instance? I
didn't know that. The "Davinci" SPI IP has 8 chip selects though...

Just be careful when using gpio for chip selects outside, like this.
The GPIO subsystem and the SPI subsystem aren't connected, directly, and
even if you pull a GPIO line and then immediately issue a spi_async
write (in the kernel, or what ever the equivalent in spidev land is),
there's no hard time requirement that the SPI write goes out on the
wire right away, it can be buffered and spi bus actions can, under some
use cases, be reordered (ie: not always in fifo order).

There's a solution for this if you support optional GPIO-based chip
selects from within the SPI master driver. Within the constraints of the
s/w-based toggling of the GPIO CS before executing the transfer or dma
request and the completion event, it allows reasonable control of the CS
timing...though not as good as just programming the h/w CS. Many SPI master
drivers implement this including spi-davinci.c. Unfortunately, the McSPI
driver doesn't yet support this...it awaits a needy individual with a
patch.

-Matt

Page 4141 (section 24.1.2) of the am335x TRM (rev D) says chip selects 2
and 3 are not pinned out. That led me to assume the silicon had 4 chip
selects but only 2 pinned out. Whether there's other parts available
with McSPI and 4 chip selects, I assumed. Sorry if that's not true, I
had remembered other chips that probably use other SPI controllers.

A quick grep through kernel source turns up that OMAP44xx might have
McSPI and 4 chip selects, but I'm not as familiar with that family nor
do I have a data sheet for it.

-Andrew

The point you bring up with the chip select lines is very valid, the
issue is (which would be solved with a kernel driver :wink: ) that I am
using GPIO lines for chip selects as the custom FPGA (a legacy design
being re-used) requires chip selects for reads and writes, the
beaglebone spidev driver has no capability for gpio chip selects and I
currently have 3 (up to 6 in the future) FPGA's connected to one board -
which is currently 6 chip selects (3 read, 3 write) - while the
beaglebone only has 3 'real' chip selects over 2 SPI Busses if I recall
correctly.

2 SPI buses, each with 2 chip-selects. If the data sheet is to be
believed. I believe the silicon can support more, but they're not
balled out on the am33xx chips. Other TI ARM parts ball out more SPI
buses and chip selects, the am33xx is a bit stingy.

Other parts with McSPI have greater than 2 chip selects per instance? I
didn't know that. The "Davinci" SPI IP has 8 chip selects though...

Just be careful when using gpio for chip selects outside, like this.
The GPIO subsystem and the SPI subsystem aren't connected, directly, and
even if you pull a GPIO line and then immediately issue a spi_async
write (in the kernel, or what ever the equivalent in spidev land is),
there's no hard time requirement that the SPI write goes out on the
wire right away, it can be buffered and spi bus actions can, under some
use cases, be reordered (ie: not always in fifo order).

There's a solution for this if you support optional GPIO-based chip
selects from within the SPI master driver. Within the constraints of the
s/w-based toggling of the GPIO CS before executing the transfer or dma
request and the completion event, it allows reasonable control of the CS
timing...though not as good as just programming the h/w CS. Many SPI master
drivers implement this including spi-davinci.c. Unfortunately, the McSPI
driver doesn't yet support this...it awaits a needy individual with a
patch.

I did start looking into this, but alas my knowledge was not up to scratch.

I have started coding my new SPI module and I have the 'spike' driver running along with my own custom char driver module. Now just to merge the two together with a bit of ioctl and gpio magic then I'm off to rainbow land where everything falls into place for ever and ever whileI can glare down at the measly user-space mortals with disdain :wink:

> Other parts with McSPI have greater than 2 chip selects per instance? I
> didn't know that. The "Davinci" SPI IP has 8 chip selects though...

Page 4141 (section 24.1.2) of the am335x TRM (rev D) says chip selects 2
and 3 are not pinned out. That led me to assume the silicon had 4 chip
selects but only 2 pinned out. Whether there's other parts available
with McSPI and 4 chip selects, I assumed. Sorry if that's not true, I
had remembered other chips that probably use other SPI controllers.

Hrm, I hadn't noticed that before, thanks. I was just thinking that I
hadn't seen any of our parts with McSPI bring out >2 CSes before.

A quick grep through kernel source turns up that OMAP44xx might have
McSPI and 4 chip selects, but I'm not as familiar with that family nor
do I have a data sheet for it.

We seem to have the same level of familiarity with OMAP44xx. There's
some folks on the list that should be able to confirm/deny off the top
of their head though. :wink:

-Matt