Difference between revisions of "Talk:BeagleBoard/Mikrobus Support"
(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 21:19, 6 April 2020
I propose the following phases:
Contents
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.