|
|
|
|
#!/bin/sh
|
|
|
|
|
# Based on ar71xx 10-ath9k-eeprom
|
|
|
|
|
|
|
|
|
|
[ -e /lib/firmware/$FIRMWARE ] && exit 0
|
|
|
|
|
|
|
|
|
|
. /lib/functions.sh
|
|
|
|
|
. /lib/functions/system.sh
|
|
|
|
|
. /lib/upgrade/nand.sh
|
|
|
|
|
|
|
|
|
|
# xor multiple hex values of the same length
|
|
|
|
|
xor() {
|
|
|
|
|
local val
|
|
|
|
|
local ret="0x$1"
|
|
|
|
|
local retlen=${#1}
|
|
|
|
|
|
|
|
|
|
shift
|
|
|
|
|
while [ -n "$1" ]; do
|
|
|
|
|
val="0x$1"
|
|
|
|
|
ret=$((ret ^ val))
|
|
|
|
|
shift
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
printf "%0${retlen}x" "$ret"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_eeprom_die() {
|
|
|
|
|
echo "ath9k eeprom: $*"
|
|
|
|
|
exit 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_eeprom_extract_raw() {
|
|
|
|
|
local source=$1
|
|
|
|
|
local offset=$2
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
local swap=$3
|
|
|
|
|
local size=4096
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
local bs=1
|
|
|
|
|
local conv=
|
|
|
|
|
|
|
|
|
|
if [ $swap -gt 0 ]; then
|
|
|
|
|
bs=2
|
|
|
|
|
conv="conv=swab"
|
|
|
|
|
size=$((size / bs))
|
|
|
|
|
offset=$((offset / bs))
|
|
|
|
|
fi
|
|
|
|
|
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
dd if=$source of=/lib/firmware/$FIRMWARE bs=$bs skip=$offset count=$size $conv 2>/dev/null || \
|
|
|
|
|
ath9k_eeprom_die "failed to extract from $mtd"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_eeprom_extract_reverse() {
|
|
|
|
|
local part=$1
|
|
|
|
|
local offset=$2
|
|
|
|
|
local count=$3
|
|
|
|
|
local mtd
|
|
|
|
|
local reversed
|
|
|
|
|
local caldata
|
|
|
|
|
|
|
|
|
|
mtd=$(find_mtd_chardev "$part")
|
|
|
|
|
reversed=$(hexdump -v -s $offset -n $count -e '/1 "%02x "' $mtd)
|
|
|
|
|
|
|
|
|
|
for byte in $reversed; do
|
|
|
|
|
caldata="\x${byte}${caldata}"
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
printf "%b" "$caldata" > /lib/firmware/$FIRMWARE
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_eeprom_extract() {
|
|
|
|
|
local part=$1
|
|
|
|
|
local offset=$2
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
local swap=$3
|
|
|
|
|
local mtd
|
|
|
|
|
|
|
|
|
|
mtd=$(find_mtd_chardev $part)
|
|
|
|
|
[ -n "$mtd" ] || \
|
|
|
|
|
ath9k_eeprom_die "no mtd device found for partition $part"
|
|
|
|
|
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract_raw $mtd $offset $swap
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_ubi_eeprom_extract() {
|
|
|
|
|
local part=$1
|
|
|
|
|
local offset=$2
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
local swap=$3
|
|
|
|
|
local ubidev=$(nand_find_ubi $CI_UBIPART)
|
|
|
|
|
local ubi
|
|
|
|
|
|
|
|
|
|
ubi=$(nand_find_volume $ubidev $part)
|
|
|
|
|
[ -n "$ubi" ] || \
|
|
|
|
|
ath9k_eeprom_die "no UBI volume found for $part"
|
|
|
|
|
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract_raw /dev/$ubi $offset $swap
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_patch_fw_mac_crc() {
|
|
|
|
|
local mac=$1
|
|
|
|
|
local mac_offset=$2
|
|
|
|
|
local chksum_offset=$((mac_offset - 10))
|
|
|
|
|
|
|
|
|
|
ath9k_patch_fw_mac "${mac}" "${mac_offset}" "${chksum_offset}"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ath9k_patch_fw_mac() {
|
|
|
|
|
local mac=$1
|
|
|
|
|
local mac_offset=$2
|
|
|
|
|
local chksum_offset=$3
|
|
|
|
|
local xor_mac
|
|
|
|
|
local xor_fw_mac
|
|
|
|
|
local xor_fw_chksum
|
|
|
|
|
|
|
|
|
|
[ -z "$mac" -o -z "$mac_offset" ] && return
|
|
|
|
|
|
|
|
|
|
[ -n "$chksum_offset" ] && {
|
|
|
|
|
xor_mac=${mac//:/}
|
|
|
|
|
xor_mac="${xor_mac:0:4} ${xor_mac:4:4} ${xor_mac:8:4}"
|
|
|
|
|
|
|
|
|
|
xor_fw_mac=$(hexdump -v -n 6 -s $mac_offset -e '/1 "%02x"' /lib/firmware/$FIRMWARE)
|
|
|
|
|
xor_fw_mac="${xor_fw_mac:0:4} ${xor_fw_mac:4:4} ${xor_fw_mac:8:4}"
|
|
|
|
|
|
|
|
|
|
xor_fw_chksum=$(hexdump -v -n 2 -s $chksum_offset -e '/1 "%02x"' /lib/firmware/$FIRMWARE)
|
|
|
|
|
xor_fw_chksum=$(xor $xor_fw_chksum $xor_fw_mac $xor_mac)
|
|
|
|
|
|
|
|
|
|
printf "%b" "\x${xor_fw_chksum:0:2}\x${xor_fw_chksum:2:2}" | \
|
|
|
|
|
dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1 seek=$chksum_offset count=2
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1 seek=$mac_offset count=6
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case "$FIRMWARE" in
|
|
|
|
|
"ath9k-eeprom-pci-0000:00:0e.0.bin" | \
|
|
|
|
|
"ath9k-eeprom-pci-0000:01:00.0.bin" | \
|
|
|
|
|
"ath9k-eeprom-pci-0000:02:00.0.bin")
|
|
|
|
|
board=$(board_name)
|
|
|
|
|
|
|
|
|
|
case "$board" in
|
|
|
|
|
arcadyan,arv7518pw)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "boardconfig" 1024 1
|
|
|
|
|
;;
|
|
|
|
|
arcadyan,arv8539pw22)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "art" 1024 1
|
|
|
|
|
;;
|
|
|
|
|
bt,homehub-v2b)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "art" 0 1
|
|
|
|
|
ath9k_patch_fw_mac_crc "00:00:00:00:00:00" 524
|
|
|
|
|
;;
|
|
|
|
|
bt,homehub-v3a)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "art-copy" 0 1
|
|
|
|
|
ath9k_patch_fw_mac_crc $(macaddr_add $(mtd_get_mac_ascii uboot_env ethaddr) +2) 268
|
|
|
|
|
;;
|
|
|
|
|
bt,homehub-v5a)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_ubi_eeprom_extract "caldata" 4096 0
|
|
|
|
|
ath9k_patch_fw_mac_crc $(macaddr_add $(mtd_get_mac_binary_ubi caldata 4364) +2) 268
|
|
|
|
|
;;
|
|
|
|
|
netgear,dgn3500|netgear,dgn3500b)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "calibration" 61440 0
|
|
|
|
|
ath9k_patch_fw_mac_crc $(macaddr_add $(mtd_get_mac_ascii uboot-env ethaddr) +2) 524
|
|
|
|
|
;;
|
|
|
|
|
avm,fritz3370-rev2-hynix|\
|
|
|
|
|
avm,fritz3370-rev2-micron)
|
|
|
|
|
ath9k_eeprom_extract_reverse "urlader" 5441 1088
|
|
|
|
|
;;
|
|
|
|
|
avm,fritz7312|avm,fritz7320|avm,fritz7360sl)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "urlader" 2437 0
|
|
|
|
|
;;
|
|
|
|
|
tplink,tdw8970|tplink,tdw8980)
|
lantiq: fix ath9k EEPROM data swapping for some devices
The EEPROM data in the flash of the ARV7518PW, ARV8539PW22,
BTHOMEHUBV2B and BTHOMEHUBV3A is stored byte-swapped (swab16), meaning
that for example the ath9k base_eep_header fields "version" (high and
low byte), "opCapFlags" and "eepMisc" are swapped (the latter ones are
just 1 byte wide, thus their position is swapped).
The old "ath,eep-endian" property enabled the corresponding swapping
logic in the ath9k driver (swab16 in ath9k_hw_nvram_swap_data, which is
based on the magic bytes in the EEPROM data which have nothing to do
with the calibration data - thus this logic should not be used
anymore).
Since we have switched to the upstream ath9k devicetree bindings there
is no binding anymore which enables swab16 in ath9k (as this logic is
not recommended anymore as explained above), leading to ath9k
initialization errors:
ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
(this shows that the version field is swapped, expected values are VER
0x000E and REV 0x0001)
Swapping the ath9k calibration data when extracting it from the flash
fixes the devices listed above (all other devices do not require
additional swapping, since the position of the fields is already as
expected by ath9k). This allows ath9k to read the version correctly
again, as well as the more important "eepmisc" field (which is used for
determining whether the data inside the EEPROM is Big or Little Endian
which is required to parse the EEPROM contents correctly).
Fixes: a20616863d3 ("lantiq: use ath9k device tree bindings
binding/owl-loader")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
8 years ago
|
|
|
ath9k_eeprom_extract "boardconfig" 135168 0
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
ath9k_eeprom_die "board $board is not supported yet"
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
;;
|
|
|
|
|
esac
|
