[RFC] Beaglebone spidev and capes

Hi,

We're gearing up for a 3.2 based beaglebone kernel that adds EEPROM parsing for capes and we need feedback on what the defaults should be when no capes are attached. A few examples to get the discussion started:

* One GPIO as w1-gpio master
* Init spi0 or spi1 as spidev

What are your thoughts on that and who want to add the code that checks for cape pin allocation conflicts?

regards,

Koen

Hi Koen,

Could you please elaborate a bit? I've just finished my cape hardware design and haven't looked into the details of the sw yet. You're probably referring to the pin-mux settings?
Is the 'default' situation (after probing with no capes attached) any different from the configuration before probing?
I would expect the configuration 'before probing' to be all inputs (except for the eeprom interface). After probing it should be as specified by the cape.
But this does not cover the situation when a new cape (with a possibly still empty EEPROM) is attached...

So shouldn't the defaults be 'very safe', i.e. configure no outputs unless needed for basic operation and unless overridden by the cape's EEPROM.
If someone wants to experiment with the hardware it's always possible to change the mux settings afterwards (that's what I've been doing up to now).

Is there a reason one would want to have outputs configured that aren't connected to anything?

Just my 2 cents...,

Cheers,
Bas

Hi,

We're gearing up for a 3.2 based beaglebone kernel that adds EEPROM parsing for capes and we need feedback on what the defaults should be when no capes are attached. A few examples to get the discussion started:

* One GPIO as w1-gpio master
* Init spi0 or spi1 as spidev

What are your thoughts on that and who want to add the code that checks for cape pin allocation conflicts?

regards,

Koen

Hi Koen,

Could you please elaborate a bit? I've just finished my cape hardware design and haven't looked into the details of the sw yet. You're probably referring to the pin-mux settings?
Is the 'default' situation (after probing with no capes attached) any different from the configuration before probing?

Currently, no. But if we implement the above suggestions the spi0 pins would initialized as SPI, with clock and DO being outputs and P8_6 an input for one-wire after probing.

I would expect the configuration 'before probing' to be all inputs (except for the eeprom interface). After probing it should be as specified by the cape.
But this does not cover the situation when a new cape (with a possibly still empty EEPROM) is attached...

A cape with no EEPROM or an empty one still counts as no cape since that's the only way we can detect one.

So shouldn't the defaults be 'very safe', i.e. configure no outputs unless needed for basic operation and unless overridden by the cape's EEPROM.
If someone wants to experiment with the hardware it's always possible to change the mux settings afterwards (that's what I've been doing up to now).

There are 2 different things to consider:

1) hardware state of the pins (input, output, high-z, etc)
2) software state of the functions

For e.g. P8_6 the hw state can be input, no pullups and be muxed to GPMC AD3 (mode 0 for P8_6). But we give gpio1_3 (mode 7 for P8_6) to w1-gpio in the kernel. You will only notice the change if you change the mode to 7 and/or you want to claim gpio1_3 for something else.

For the w1 example the pin would be muxed to mode 7 after the kernel finds no capes attached (or the attached capes don't use P8_6).

Does this clear things up?

regards,

Koen

>> Hi,
>>
>> We're gearing up for a 3.2 based beaglebone kernel that adds EEPROM
>> parsing for capes and we need feedback on what the defaults should be
>> when no capes are attached. A few examples to get the discussion
>> started:
>>
>> * One GPIO as w1-gpio master
>> * Init spi0 or spi1 as spidev
>>
>> What are your thoughts on that and who want to add the code that checks
>> for cape pin allocation conflicts?
>>
>> regards,
>>
>> Koen
>
> Hi Koen,
>
> Could you please elaborate a bit? I've just finished my cape hardware
> design and haven't looked into the details of the sw yet. You're
> probably referring to the pin-mux settings? Is the 'default' situation
> (after probing with no capes attached) any different from the
> configuration before probing?

Currently, no. But if we implement the above suggestions the spi0 pins
would initialized as SPI, with clock and DO being outputs and P8_6 an
input for one-wire after probing.

> I would expect the configuration 'before probing' to be all inputs
> (except for the eeprom interface). After probing it should be as
> specified by the cape. But this does not cover the situation when a new
> cape (with a possibly still empty EEPROM) is attached...

A cape with no EEPROM or an empty one still counts as no cape since that's
the only way we can detect one.

Surely you can differentiate between no EEPROM and an empty one, or at
least make a good stab at it, enough to be aware there is one there and
to put the system into a defensive mode (i.e. no outputs) ready for
programming the EEPROM. The EEPROM would at least respond to commands
and give a result of a known length (the size of the EEPROM is fixed)
even if it gave garbage values.

David

Hi,

We're gearing up for a 3.2 based beaglebone kernel that adds EEPROM parsing for capes and we need feedback on what the defaults should be when no capes are attached. A few examples to get the discussion started:

* One GPIO as w1-gpio master
* Init spi0 or spi1 as spidev

What are your thoughts on that and who want to add the code that checks for cape pin allocation conflicts?

regards,

Koen

Hi Koen,

Could you please elaborate a bit? I've just finished my cape hardware design and haven't looked into the details of the sw yet. You're probably referring to the pin-mux settings?
Is the 'default' situation (after probing with no capes attached) any different from the configuration before probing?

Currently, no. But if we implement the above suggestions the spi0 pins would initialized as SPI, with clock and DO being outputs and P8_6 an input for one-wire after probing.

I don't get it, is one-wire part of the standard configuration?

I would expect the configuration 'before probing' to be all inputs (except for the eeprom interface). After probing it should be as specified by the cape.
But this does not cover the situation when a new cape (with a possibly still empty EEPROM) is attached...

A cape with no EEPROM or an empty one still counts as no cape since that's the only way we can detect one.

It shouldn't be hard to differentiate between an empty EEPROM and the 'no EEPROM' situation. Finding an empty EEPROM should make an exception to the configuration process and retain the 'safe' configuration. That makes it possible to load the initial EEPROM contents without destroying some hardware (without special hardware to program the EEPROM during cape production).

So shouldn't the defaults be 'very safe', i.e. configure no outputs unless needed for basic operation and unless overridden by the cape's EEPROM.
If someone wants to experiment with the hardware it's always possible to change the mux settings afterwards (that's what I've been doing up to now).

There are 2 different things to consider:

1) hardware state of the pins (input, output, high-z, etc)
2) software state of the functions

For e.g. P8_6 the hw state can be input, no pullups and be muxed to GPMC AD3 (mode 0 for P8_6). But we give gpio1_3 (mode 7 for P8_6) to w1-gpio in the kernel. You will only notice the change if you change the mode to 7 and/or you want to claim gpio1_3 for something else.

For the w1 example the pin would be muxed to mode 7 after the kernel finds no capes attached (or the attached capes don't use P8_6).

Does this clear things up?

As long as the hardware state is 'safe' until properly configured by the cape, I'm fine.
After that there's nothing that can't be fixed from userspace, is there?

Regards,

Bas

Hi,

We're gearing up for a 3.2 based beaglebone kernel that adds EEPROM parsing for capes and we need feedback on what the defaults should be when no capes are attached. A few examples to get the discussion started:

* One GPIO as w1-gpio master
* Init spi0 or spi1 as spidev

What are your thoughts on that and who want to add the code that checks for cape pin allocation conflicts?

regards,

Koen

Hi Koen,

Could you please elaborate a bit? I've just finished my cape hardware design and haven't looked into the details of the sw yet. You're probably referring to the pin-mux settings?
Is the 'default' situation (after probing with no capes attached) any different from the configuration before probing?

Currently, no. But if we implement the above suggestions the spi0 pins would initialized as SPI, with clock and DO being outputs and P8_6 an input for one-wire after probing.

I don't get it, is one-wire part of the standard configuration?

I would expect the configuration 'before probing' to be all inputs (except for the eeprom interface). After probing it should be as specified by the cape.
But this does not cover the situation when a new cape (with a possibly still empty EEPROM) is attached...

A cape with no EEPROM or an empty one still counts as no cape since that's the only way we can detect one.

It shouldn't be hard to differentiate between an empty EEPROM and the 'no EEPROM' situation. Finding an empty EEPROM should make an exception to the configuration process and retain the 'safe' configuration. That makes it possible to load the initial EEPROM contents without destroying some hardware (without special hardware to program the EEPROM during cape production).

So shouldn't the defaults be 'very safe', i.e. configure no outputs unless needed for basic operation and unless overridden by the cape's EEPROM.
If someone wants to experiment with the hardware it's always possible to change the mux settings afterwards (that's what I've been doing up to now).

There are 2 different things to consider:

1) hardware state of the pins (input, output, high-z, etc)
2) software state of the functions

For e.g. P8_6 the hw state can be input, no pullups and be muxed to GPMC AD3 (mode 0 for P8_6). But we give gpio1_3 (mode 7 for P8_6) to w1-gpio in the kernel. You will only notice the change if you change the mode to 7 and/or you want to claim gpio1_3 for something else.

For the w1 example the pin would be muxed to mode 7 after the kernel finds no capes attached (or the attached capes don't use P8_6).

Does this clear things up?

As long as the hardware state is 'safe' until properly configured by the cape, I'm fine.
After that there's nothing that can't be fixed from userspace, is there?

Regards,

Bas

From a uboot point of view, you will read back 0xFF in both cases, so that's no help.

regards,

Koen

I agree with leaving the bone expansion signals safe by default.

Initially, only the I2C signals that read the EEPROM would be active to allow reading the EEPROM and cape configuration. Like said before, this would also allow some bone app program the EEPROM of a cape for those that lack the hardware to do that.

IMO the expansion signals should be left in high impedance state and only driven in case some cape requests them.

If uboot is unable to detect the EEPROM, I may hope it is not going to change the configuration (at least not into an 'unsafe' state), is it?
Why do I get the impression I'm missing something here...

Cheers,

Bas

Lets hope if you are going to use anything other than 8bit identifier
IDs you at least specify the Endian and not screw it up like on the
BeagleBoard expansion board identifier spec. which left how the data
was actually placed in EEPROM unspecified.

The format is specified in the System Reference Manual for the BeagleBone.

http://circuitco.com/support/index.php?title=BeagleBone#Hardware_Files

Gerald

I agree with leaving the bone expansion signals safe by default.

Koen, for one-wire support, can't it be enabled in the kernel and for
the port while the pin is still in a "safe" mode? I'd guess that the
kernel will try to own the direction of the pin, since this is a
bi-directional mode, but is there another mode the mux can be put in
by default? Enabling the mux in user space is easy, allowing us to
enable the one-wire support. Or, will the kernel puke when the mux is
in the wrong mode? And, for that matter, is there a safe mode that
isn't GPIO?

Initially, only the I2C signals that read the EEPROM would be active to
allow reading the EEPROM and cape configuration. Like said before, this
would also allow some bone app program the EEPROM of a cape for those that
lack the hardware to do that.

IMO the expansion signals should be left in high impedance state and only
driven in case some cape requests them.

I believe the safest mode is Hi-Z with a pull-down. It isn't good to
let inputs simply float. There are certainly going to be exceptions
to that on the Bone and I hope we can clearly document them here.
Certainly the I2C bus where the EEPROM will be connected won't be in a
Hi-Z+pulldown state.

--
cheers,
tone

I think we need to add some mux settings to the main-board EEPROM such
that we can save off some personal settings. It should be easy to get
back to the default state.

All, if you are able, it would be great to move this discussion into
the form of patches in the next couple of days. It really helps with
clarity. I don't want to push anyone out of the discussion, but
resolution will take a long time if we keep it at the wishlist level.
Koen has provided a starting point and I suspect there will be an
effort to get his patches for working with the EEPROMs and Capes onto
Vaibhav's tree.

I agree with leaving the bone expansion signals safe by default.

Koen, for one-wire support, can't it be enabled in the kernel and for
the port while the pin is still in a "safe" mode? I'd guess that the
kernel will try to own the direction of the pin, since this is a
bi-directional mode, but is there another mode the mux can be put in
by default? Enabling the mux in user space is easy, allowing us to
enable the one-wire support. Or, will the kernel puke when the mux is
in the wrong mode? And, for that matter, is there a safe mode that
isn't GPIO?

Setting the mux in userspace works, but setting the direction but doesn't work (maybe PEBKAC).

Initially, only the I2C signals that read the EEPROM would be active to
allow reading the EEPROM and cape configuration. Like said before, this
would also allow some bone app program the EEPROM of a cape for those that
lack the hardware to do that.

IMO the expansion signals should be left in high impedance state and only
driven in case some cape requests them.

I believe the safest mode is Hi-Z with a pull-down. It isn't good to
let inputs simply float. There are certainly going to be exceptions
to that on the Bone and I hope we can clearly document them here.
Certainly the I2C bus where the EEPROM will be connected won't be in a
Hi-Z+pulldown state.

Currently all the LCD signals come up as outputs....

--
cheers,
tone

I think we need to add some mux settings to the main-board EEPROM such
that we can save off some personal settings. It should be easy to get
back to the default state.

All, if you are able, it would be great to move this discussion into
the form of patches in the next couple of days. It really helps with
clarity. I don't want to push anyone out of the discussion, but
resolution will take a long time if we keep it at the wishlist level.
Koen has provided a starting point and I suspect there will be an
effort to get his patches for working with the EEPROMs and Capes onto
Vaibhav's tree.

How does the eeprom readout in the kernel work together with DT?