User talk:MrNuke: Difference between revisions

From coreboot
Jump to navigation Jump to search
Line 26: Line 26:


* Do we want to expose or hide the block nature of some devces (i.e. force reading multiples of blocksize, or allow reading any number of bytes, with no alignment requirement) ?
* Do we want to expose or hide the block nature of some devces (i.e. force reading multiples of blocksize, or allow reading any number of bytes, with no alignment requirement) ?
* How do we connect the dots, such that most of the details can be handled transparently ?
* How simple or complex do we want the API to be such that it can work in any stage (including bootblock, assuming some SRAM and a stack are available) ?
* Can we integrate this into '''libpayload''' such that the same sources can be used for both coreboot and libpayload ?
** think "Device specfic storage drivers -> [*] Allwinner A10 MMC driver" in '''libpayload''' config

Revision as of 01:29, 11 January 2014

Ideas for generic handling of devices

Proposal 1: Unified API

Chan is an IO channel.

This struct is used in Inferno and has been for a long time; so it works. It's also in the opcodes somewhat like what we did for EMMC on ARM.

struct Dev
{
	char*	name;
	void	(*reset)(void);
	void	(*init)(void);
	void	(*shutdown)(void);
	Chan*	(*attach)(char*); /* tell the device you want to use it */
	Walkqid*	(*walk)(Chan*, Chan*, char**, int); /* walk to a name in the device's managed name space; return a handle */
	int	(*stat)(Chan*, uchar*, int); // status info
	Chan*	(*open)(Chan*, int); /* get access to a resource in the device name space */
	void	(*close)(Chan*); /* tell it you are done with whatever it is. */
	long	(*read)(Chan*, void*, long, vlong);
	long	(*write)(Chan*, void*, long, vlong);
	void	(*power)(int);	/* power mgt: power(1) ? on, power (0) ? off */
};

Questions

  • Do we want to expose or hide the block nature of some devces (i.e. force reading multiples of blocksize, or allow reading any number of bytes, with no alignment requirement) ?
  • How do we connect the dots, such that most of the details can be handled transparently ?
  • How simple or complex do we want the API to be such that it can work in any stage (including bootblock, assuming some SRAM and a stack are available) ?
  • Can we integrate this into libpayload such that the same sources can be used for both coreboot and libpayload ?
    • think "Device specfic storage drivers -> [*] Allwinner A10 MMC driver" in libpayload config