| 5 | The [source:soft/giet_vm/giet_drivers/ioc_driver.c ioc_driver.c] and [source:soft/giet_vm/giet_drivers/ioc_driver.h ioc_driver.h] files define an abstract, block oriented, mass storage driver. |
| 6 | |
| 7 | This abstact driver define a generic API, supporting various physical disks or virtual disks controlers: |
| 8 | * vci_block_device : single channel physical disk with DMA capacity => bdv_driver |
| 9 | * vci_ahci : multi channels physical disk => hba_driver |
| 10 | * sd_card : single channel physical SD card => sdc_driver |
| 11 | * ramdisk : single channel memory mapped virtual disk => rdk_driver |
| 12 | |
| 13 | It can exist only one block-device type in the architecture, that must be defined by one of the following configuration variables in hard_config.h file: USE_IOC_BDV, USE_IOC_SDC, USE_IOC_HBA, USE_IOC_RDK. |
| 14 | |
| 15 | Any physical block device driver xxx must provide the following API: |
| 16 | * _xxx_init() |
| 17 | * _xxx_read() |
| 18 | * _xxx_write() |
| 19 | * _xxx_get_status() |
| 20 | * _xxx_get_block_size() |
| 21 | |
| 22 | The _ioc_read() and _ioc_write() functions are always blocking for the calling user program. |
| 23 | These functions compute the physical address of the memory buffer before calling the proper physical device. This drivers makes the assumption that the user buffer is mapped to a contiguous physical buffer because, this is granted by the GIET-VM physical memory allocator. |
| 24 | |
| 25 | These functions can be called in 3 modes: |
| 26 | * In BOOT mode, these functions use the buffer virtual address as a physical address if the MMU is not activated. They make a V2P translation if the MMU is activated. This mode is used to load the map.bin file (before memory activation), or to load the various .elf files (after MMU activation). |
| 27 | * In KERNEL mode, these functions make a V2P translation to compute the buffer physical address. There is no checking of user access right to the memory buffer. This mode must be used for an ''open'' system call. |
| 28 | * In USER mode, these functions make a V2P translation to compute the buffer physical address. The user access right to the memory buffer are checked. This mode must be used for a ''read'' or ''write'' system call. |
| 29 | |
| 30 | The memory buffer must fulfill the following conditions: |
| 31 | * The buffer must be word aligned, |
| 32 | * The buffer must be mapped in user space for an user access, |
| 33 | * The buffer must be writable in case of (to_mem) access, |
| 34 | * All physical pages occupied by the user buffer must be contiguous |
| 35 | Exit if these conditions are not verified. |
| 36 | |
| 37 | The SEG_IOC_BASE virtual base address must be defined in hard_config.h, as it is used by the BDV, HBA and SPI drivers. |
| 38 | If the RAMDISK is used, an extra memory segment with virtual base address SEG_RDK_BASE, used by RDK driver, must be defined in hard_config.h. |
| 39 | |
| 40 | The IOMMU is not supported yet, but the method is the following: A fixed size 2 Mbytes vseg is allocated to the IOC peripheral, in the I/O virtual space, and the user buffer is dynamically remapped to one single big page in the IOMMU page table. The user buffer is unmapped by the _ioc_completed() function when the transfer is completed. |