On 27/09/2016 08:49, Chris Blake wrote:
> 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
>
Ok, i merged the patch just now. we should consider moving those 2
chunks into a generic place and reusing them for all meraki devices.
John
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
