Hey John, >> --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom >> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom >> @@ -73,6 +73,16 @@ case "$FIRMWARE" in >> ath9k_eeprom_extract "caldata" 4096 2048 >> ath9k_patch_firmware_mac $(mtd_get_mac_binary caldata 0) >> ;; >> + z1) >> + . /lib/upgrade/nand.sh >> + >> + if [ -n "$(nand_find_volume ubi0 caldata)" ]; then >> + ath9k_ubi_eeprom_extract "caldata" 4096 2048 >> + else >> + ath9k_eeprom_extract "origcaldata" 4096 2048 >> + fi >> + ath9k_patch_firmware_mac $(macaddr_add >> $(mtd_get_mac_binary_ubi board-config 102) +2) >> + ;; > > this chunk and the one below look weird. can you explain why there are 2 > caldata blocks please ? > > John >
Similar to the Meraki MR18 [0], the Z1 has a MTD partition (origcaldata) and a UBI partition (caldata) that holds the caldata for the board. The reason this check is in place is to ensure that caldata is preferred over origcaldata, as origcaldata uses a different ECC format than the UBI partition. We also update caldata with the contents of origcaldata if the partition exists at the time of a sysupgrade [1] as earlier meraki firmwares do not populate this partition correctly, or at all. [0]: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom#L63 [1]: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/lib/upgrade/merakinand.sh#L64 Regards, Chris Blake _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
