Re: ID page of EEPROM
Hello, Yes, EEPROMs are small and are managed as a virtual fixed-size file. The EEPROM bytes can be erased and written individually, which means the erase block size of the associated mtd device would be one byte long, which is uselessly complex. Using larger block sizes would make the driver worse as changing one byte would require a read-modify-write from user space. And EEPROM usually dont have an ERASE command, just a WRITE, so it's not a good match for the MTD framework. No JEDEC RDID identification either. Also, when I wrote the EEPROM driver, there was no generic way to access MTD devices. - You can add ioctls to the EEPROM drivers, just make sure you define these in terms of generic functions that have potential for implementation on several devices. For some devices, the built-in MAC address is part of the main memory plane, so there is no specific access function, but ID page is one of these functions that would benefit from dedicated IOCTLs. Please plan a way to indicate the size of this ID page to the user, because I'm sure the size is not the same on all devices. Also please add flags to devices supported by the driver so the ID page IOCTLs are not activated for devices that dont have ID memory. I can proof read your code to offer suggestions if you wish. Sebastien Le 07/11/2023 à 15:31, Gregory Nutt a écrit : On 11/4/2023 6:12 PM, Robert Middleton wrote: I'm a little confused as to what the difference is between the MTD folder and the EEPROM folder. It seems that both folders have support for the at24xx and at25xx series of chips, so it's not obvious which one is better. MTD is more of a "heavyweight" solution that can support a higher level of functionality on Memory Technology Devices (MTDs) such as file systems or wear-leveling layers. Most EEPPROMs are small, however, and it may not be practical to support a file system on top of the EEPROM. So the lightweight character driver layer from Sebastien Lorquet. This lightweight layer will support only character-oriented I/O via lseek, read, and write
Re: ID page of EEPROM
On 11/4/2023 6:12 PM, Robert Middleton wrote: I'm a little confused as to what the difference is between the MTD folder and the EEPROM folder. It seems that both folders have support for the at24xx and at25xx series of chips, so it's not obvious which one is better. MTD is more of a "heavyweight" solution that can support a higher level of functionality on Memory Technology Devices (MTDs) such as file systems or wear-leveling layers. Most EEPPROMs are small, however, and it may not be practical to support a file system on top of the EEPROM. So the lightweight character driver layer from Sebastien Lorquet. This lightweight layer will support only character-oriented I/O via lseek, read, and write
Re: ID page of EEPROM
Thanks for the info. So does it make more sense to add the new functionality as part of the EEPROM driver(drivers/eeprom/spi_xx25xx.c) or under the MTD(drivers/mtd/??). I assume anything added should be under the EEPROM folder, but I'm a little confused as to what the difference is between the MTD folder and the EEPROM folder. It seems that both folders have support for the at24xx and at25xx series of chips, so it's not obvious which one is better. I was planning to add it to the drivers/eeprom/spi_xx25xx.c. -Robert Middleton On Fri, Nov 3, 2023 at 8:17 PM Gregory Nutt wrote: > > > On 11/3/2023 4:02 PM, Robert Middleton wrote: > > Hi, > > > > I am working on a project that will need to be able to read/write the > > ID page of an EEPROM(currently a M95M02 SPI device from ST). From the > > code that I have seen, it seems that this chip is already supported, > > but there is no code to read/write the device ID page. I'm looking to > > add support, but I have some questions: > > > > 1. There are currently no IOCTLs defined for EEPROM devices, should I > > add a new IOCTL base or add an extra one to the MTD IOCTLs? > See below > > 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird, > > should that be something else? > > ENOTTY is correct. See https://en.wikipedia.org/wiki/Not_a_typewriter > or > https://cwiki.apache.org/confluence/display/NUTTX/ENOTTY+ioctl%28%29+Return+Value > > This confuses a lot of people and there are numerous stack overflow > questions like yours. > > > 3. Since you could read/write the ID page, should this really be > > implemented as an IOCTL? I would assume that the functions would need > > to be more like the read/write syscalls where you pass in a buffer and > > the length(assuming you don't want to read or write the entire page). > > Would it make sense to make another node in /dev to access this page? > > This is related logic for the AT24 EEPROM. That part has an extended > memory region that holds configuration data like that factory > initialized MAC address of the SAMv71-Xult board. > See/boards/arm/samv7/samv71-xult/src/sam_ethernet.c: > >/* Configure the AT24 to access the extended memory region */ > >ret = at24->ioctl(at24, MTDIOC_EXTENDED, 1); > > That is not exactly the same functionality, but is, I think sufficiently > related to justify using IOCTLs. > > NOTE: That only uses the IOCTL to switch modes of EEPROM. Normal reads > and writes are then used to access the extended range: > >/* Read the MAC address */ > >nread = at24->read(at24, AT24XX_MACADDR_OFFSET, 6, mac); > > Using IOCTLs for reads and writes would be awkward. > > Optionally, you could treat the control memory as a separate partition, > registering the ID page like it were a different device. > > Notice that the AT24 does use an MTD IOCTL. I don't know if we want to > proliferate that naming or not? It would good to re-use it if the > semantics of the name would permit you to re-use it.
Re: ID page of EEPROM
On 11/3/2023 4:02 PM, Robert Middleton wrote: Hi, I am working on a project that will need to be able to read/write the ID page of an EEPROM(currently a M95M02 SPI device from ST). From the code that I have seen, it seems that this chip is already supported, but there is no code to read/write the device ID page. I'm looking to add support, but I have some questions: 1. There are currently no IOCTLs defined for EEPROM devices, should I add a new IOCTL base or add an extra one to the MTD IOCTLs? See below 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird, should that be something else? ENOTTY is correct. See https://en.wikipedia.org/wiki/Not_a_typewriter or https://cwiki.apache.org/confluence/display/NUTTX/ENOTTY+ioctl%28%29+Return+Value This confuses a lot of people and there are numerous stack overflow questions like yours. 3. Since you could read/write the ID page, should this really be implemented as an IOCTL? I would assume that the functions would need to be more like the read/write syscalls where you pass in a buffer and the length(assuming you don't want to read or write the entire page). Would it make sense to make another node in /dev to access this page? This is related logic for the AT24 EEPROM. That part has an extended memory region that holds configuration data like that factory initialized MAC address of the SAMv71-Xult board. See/boards/arm/samv7/samv71-xult/src/sam_ethernet.c: /* Configure the AT24 to access the extended memory region */ ret = at24->ioctl(at24, MTDIOC_EXTENDED, 1); That is not exactly the same functionality, but is, I think sufficiently related to justify using IOCTLs. NOTE: That only uses the IOCTL to switch modes of EEPROM. Normal reads and writes are then used to access the extended range: /* Read the MAC address */ nread = at24->read(at24, AT24XX_MACADDR_OFFSET, 6, mac); Using IOCTLs for reads and writes would be awkward. Optionally, you could treat the control memory as a separate partition, registering the ID page like it were a different device. Notice that the AT24 does use an MTD IOCTL. I don't know if we want to proliferate that naming or not? It would good to re-use it if the semantics of the name would permit you to re-use it.
ID page of EEPROM
Hi, I am working on a project that will need to be able to read/write the ID page of an EEPROM(currently a M95M02 SPI device from ST). From the code that I have seen, it seems that this chip is already supported, but there is no code to read/write the device ID page. I'm looking to add support, but I have some questions: 1. There are currently no IOCTLs defined for EEPROM devices, should I add a new IOCTL base or add an extra one to the MTD IOCTLs? 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird, should that be something else? 3. Since you could read/write the ID page, should this really be implemented as an IOCTL? I would assume that the functions would need to be more like the read/write syscalls where you pass in a buffer and the length(assuming you don't want to read or write the entire page). Would it make sense to make another node in /dev to access this page? -Robert Middleton
