| Message ID | cover.1689802933.git.daniel@makrotopia.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | nvmem: add block device NVMEM provider | expand |
On Wed, Jul 19, 2023 at 11:01:14PM +0100, Daniel Golle wrote: > This series is meant to open the discussion on how exactly the device tree > schema for block devices and partitions may look like, and even if using > the block layer to back the NVMEM device is at all the way to go -- to me > it seemed to be a good solution because it will be reuable e.g. for NVMe. If only NVMe did something sane there. NVMe copied the completely idiotic idea of boot partitions from eMMC/SD, and made it even worse by first requiring bit banged register access for them, and now adding a weird admin command to read them, which is not bound to a block device. If we want to support that in NVMe we'll need code in the nvme core, but I hope we can avoid it and no one sane (that is everyone but the completely clueless BIOS people at Intel) will never use this completely fucked up boot partition concept.
On 7/19/23 15:01, Daniel Golle wrote: > On embedded devices using an eMMC it is common that one or more (hw/sw) > partitions on the eMMC are used to store MAC addresses and Wi-Fi > calibration EEPROM data. > > Implement an NVMEM provider backed by block devices as typically the > NVMEM framework is used to have kernel drivers read and use binary data > from EEPROMs, efuses, flash memory (MTD), ... > > In order to be able to reference hardware partitions on an eMMC, add code > to bind each hardware partition to a specific firmware subnode. > > This series is meant to open the discussion on how exactly the device tree > schema for block devices and partitions may look like, and even if using > the block layer to back the NVMEM device is at all the way to go -- to me > it seemed to be a good solution because it will be reuable e.g. for NVMe. Is my understanding correct that these devices boot from eMMC and not over Wi-Fi? If so, why does this calibration data have to be stored on a raw block device? Why can't this information be loaded from a file on a filesystem? Thanks, Bart.
On Thu, Jul 20, 2023 at 08:30:39AM -0700, Bart Van Assche wrote: > On 7/19/23 15:01, Daniel Golle wrote: > > On embedded devices using an eMMC it is common that one or more (hw/sw) > > partitions on the eMMC are used to store MAC addresses and Wi-Fi > > calibration EEPROM data. > > > > Implement an NVMEM provider backed by block devices as typically the > > NVMEM framework is used to have kernel drivers read and use binary data > > from EEPROMs, efuses, flash memory (MTD), ... > > > > In order to be able to reference hardware partitions on an eMMC, add code > > to bind each hardware partition to a specific firmware subnode. > > > > This series is meant to open the discussion on how exactly the device tree > > schema for block devices and partitions may look like, and even if using > > the block layer to back the NVMEM device is at all the way to go -- to me > > it seemed to be a good solution because it will be reuable e.g. for NVMe. > > Is my understanding correct that these devices boot from eMMC and not over > Wi-Fi? Yes, that's right. > If so, why does this calibration data have to be stored on a raw > block device? It's just how many vendors decided to implement it in their firmware. I reckon this happened mostly out of habbit and in order to avoid any potential complexities in their manufacturing and QA processes -- most of those processes have been created in a time when NOR flash was the most common way to store firmware on embedded devices with Wi-Fi. The occurance of raw NAND and SPI-NAND didn't change much about that, most vendors still just use a raw MTD partition to store all that per-device 'factory' data. Very few have have started to use raw data inside UBI volumes (and I've been working on a UBI NVMEM driver as well). Also when it comes to eMMC they just keep doing things how they were always doing them, just that instead of a raw NOR flash, some devices nowadays come with an eMMC. Some vendors use the 'boot1' hardware partition to store things like MAC addresses at raw offsets there (GL.iNet for example [1]), others use small GPT or MBR partitions on the main hardware partition of the eMMC to store MAC addresses and calibration blobs (for example Adtran [2]). > Why can't this information be loaded from a file on a > filesystem? Having this information stored in a file on a filesystem is also an option, of course, but out in the wild you will hardly find it being done like that, for the reason stated above and also because having the OS pull the Ethernet MAC addresses somewhere from a filesystem while in early user-space will require the OS to even know about the individual hardware and how this should be done, so it's not exactly beautiful, may need fsck, mounting, ... all before the machine can become available with it's assigned MAC address on Ethernet. The RaspberryPi and other brcmfmac-based systems are the exception to the rule, here a simple text file stored on the root filesystem serves the Wi-Fi calibration. This file hence needs to be shipped with the OS instead of being stored on the device, and e.g. Raspbian does so. I suppose this is mostly because there just isn't any permanent on-board storage large enough and being a low-barrier DYI system they wanted to make it easy for users designing systems besed on that (as in: not having to mess with raw offsets or partitions, but rather just use tools like Etcher on Windows and edit CR-LF terminated text files on a FAT filesystem inside notepad...). However, practically all Qualcomm and MediaTek Wi-Fi AP/Routers which come with an eMMC come with their MAC addresses and Wi-Fi EEPROM data stored as raw data inside a hardware or software partition. [1]: https://github.com/dangowrt/linux/commit/8a24f03efb6b1dd7d8fdf68558146bacc71c2c1b [2]: https://github.com/dangowrt/linux/commit/b14c0215641047d0447956b40bd344049a11becb
On Wed, Jul 19, 2023 at 11:01:14PM +0100, Daniel Golle wrote: > On embedded devices using an eMMC it is common that one or more (hw/sw) > partitions on the eMMC are used to store MAC addresses and Wi-Fi > calibration EEPROM data. > > Implement an NVMEM provider backed by block devices as typically the > NVMEM framework is used to have kernel drivers read and use binary data > from EEPROMs, efuses, flash memory (MTD), ... > > In order to be able to reference hardware partitions on an eMMC, add code > to bind each hardware partition to a specific firmware subnode. > > This series is meant to open the discussion on how exactly the device tree > schema for block devices and partitions may look like, and even if using > the block layer to back the NVMEM device is at all the way to go -- to me > it seemed to be a good solution because it will be reuable e.g. for NVMe. Just wondering why you don't use request_firmware() in drivers which consume the data, then the logic can be moved out of kernel, and you needn't to deal with device tree & block device. Or Android doesn't support udev and initrd? Thanks, Ming
On Fri, Jul 21, 2023 at 04:32:49PM +0800, Ming Lei wrote: > On Wed, Jul 19, 2023 at 11:01:14PM +0100, Daniel Golle wrote: > > On embedded devices using an eMMC it is common that one or more (hw/sw) > > partitions on the eMMC are used to store MAC addresses and Wi-Fi > > calibration EEPROM data. > > > > Implement an NVMEM provider backed by block devices as typically the > > NVMEM framework is used to have kernel drivers read and use binary data > > from EEPROMs, efuses, flash memory (MTD), ... > > > > In order to be able to reference hardware partitions on an eMMC, add code > > to bind each hardware partition to a specific firmware subnode. > > > > This series is meant to open the discussion on how exactly the device tree > > schema for block devices and partitions may look like, and even if using > > the block layer to back the NVMEM device is at all the way to go -- to me > > it seemed to be a good solution because it will be reuable e.g. for NVMe. > > Just wondering why you don't use request_firmware() in drivers which consume > the data, then the logic can be moved out of kernel, and you needn't to deal > with device tree & block device. The thing is: Why should the OS need to know about how to read calibration to be fed into a wireless driver on a specific hardware/firmware? Or even worse: The MAC address of the main Ethernet interface? What if for one of many possible reasons the extraction script in userland gets broken and you would need to recover the system via SSH (because it's a router or switch and doesn't even have any local console)? Having information about the location of firmware artifacts be supplied by the firmware (via device tree) seems to be the natural choice, and also how it is done for devices booting off NOR or NAND flash by using the NVMEM framework. Why should eMMC be the exception? > > Or Android doesn't support udev and initrd? Yes, sure, but then the OS ROM needs to know about and handle a lot of very device-specific details in userland and if (unlike Android) the same OS ROM should run on many devices that would mean it will have to ship all of them in a huge initrd or root filesystem. Also using userspace mechanics to acquire things as basic as a MAC address seems overly complex and much more fragile than having the firmware instruct the kernel via device tree to do so. Hence, within the OpenWrt project, we've been working for years now to push for Device Tree and lately for use of the NVMEM framework, exactly to **reduce** the amount of hardware-specific knowledge in userland and get rid of shell scripts acting as hotplug handlers for firmware requests and such.
On Fri, Jul 21, 2023 at 04:32:49PM +0800, Ming Lei wrote: > On Wed, Jul 19, 2023 at 11:01:14PM +0100, Daniel Golle wrote: > > On embedded devices using an eMMC it is common that one or more (hw/sw) > > partitions on the eMMC are used to store MAC addresses and Wi-Fi > > calibration EEPROM data. > > > > Implement an NVMEM provider backed by block devices as typically the > > NVMEM framework is used to have kernel drivers read and use binary data > > from EEPROMs, efuses, flash memory (MTD), ... > > > > In order to be able to reference hardware partitions on an eMMC, add code > > to bind each hardware partition to a specific firmware subnode. > > > > This series is meant to open the discussion on how exactly the device tree > > schema for block devices and partitions may look like, and even if using > > the block layer to back the NVMEM device is at all the way to go -- to me > > it seemed to be a good solution because it will be reuable e.g. for NVMe. > > Just wondering why you don't use request_firmware() in drivers which consume > the data, then the logic can be moved out of kernel, and you needn't to deal > with device tree & block device. > > Or Android doesn't support udev and initrd? It does support initrd, but not really udev last I looked. But it does allow request_firmware() to be called at boot time, so yes, finding out why that isn't used here would be good. thanks, greg k-h