Difference between revisions of "Talk:BeagleBoard/Mikrobus Support"

From eLinux.org
Jump to: navigation, search
(Talk page autocreated when first thread was posted)
 
 
Line 1: Line 1:
 +
I propose the following phases:
  
 +
== mikroBUS bus driver with gbsim ==
 +
* Build a mikroBUS bus driver to load I2C, SPI, and UART device drivers
 +
* Instantiate the driver on PocketBeagle+TechLab using whatever device tree entries you need to define it. Define the bus, not any of the devices.
 +
* Use as generic manifests as possible with gbsim. No target specific content should go in the manifest, though a mikroBUS-specific resource could be defined.
 +
* The bus driver should be called (init/probe?) and be able to complete the platform data structure to call the (init/probe?) on the device driver such that no device tree information is required.
 +
* It might be necessary to augment Greybus with some mikroBUS-specific information, like it was a bus at the same level as I2C, SPI, etc.
 +
 +
== mikroBUS bus driver with I2C EEPROM holding manifest ==
 +
* init function fetches a Greybus manifest blob from an I2C EEPROM over the mikroBUS I2C bus.
 +
* I2C EEPROM would be manually programmed to contain the blob.
 +
* Use the Greybus code to parse the manifest, but do not require gbsim to get the data.
 +
 +
== Flesh out the driver for the remaining mikroBUS interfaces ==
 +
* Interfaces: PWM, ADC, etc.
 +
* Extra configuration information for other device types: displays, etc.
 +
 +
== Get everything working over actual Greybus ==
 +
* Start with Greybus over UART to CC1352R Launchpad with mikroBUS slots.

Latest revision as of 20:19, 6 April 2020

I propose the following phases:

mikroBUS bus driver with gbsim

  • Build a mikroBUS bus driver to load I2C, SPI, and UART device drivers
  • Instantiate the driver on PocketBeagle+TechLab using whatever device tree entries you need to define it. Define the bus, not any of the devices.
  • Use as generic manifests as possible with gbsim. No target specific content should go in the manifest, though a mikroBUS-specific resource could be defined.
  • The bus driver should be called (init/probe?) and be able to complete the platform data structure to call the (init/probe?) on the device driver such that no device tree information is required.
  • It might be necessary to augment Greybus with some mikroBUS-specific information, like it was a bus at the same level as I2C, SPI, etc.

mikroBUS bus driver with I2C EEPROM holding manifest

  • init function fetches a Greybus manifest blob from an I2C EEPROM over the mikroBUS I2C bus.
  • I2C EEPROM would be manually programmed to contain the blob.
  • Use the Greybus code to parse the manifest, but do not require gbsim to get the data.

Flesh out the driver for the remaining mikroBUS interfaces

  • Interfaces: PWM, ADC, etc.
  • Extra configuration information for other device types: displays, etc.

Get everything working over actual Greybus

  • Start with Greybus over UART to CC1352R Launchpad with mikroBUS slots.