Re: [U-Boot] Atheros "ART" data crc calculation

Hello again Allan, Can you on work device (with correct ART section and with no checksum error), enter the u-boot command - "printenv" ? Also would you please share your ART section of the same device?
Idea is this, it is necessary to calculate the checksum of ART section (only not clearly what part of the calculate, with empty sectors "FF" or workspace) in CRC32 format, then correct this checksum in "buf_crc" environment variable.
https://forum.openwrt.org/viewtopic.php?pid=153580#p153580
Best regards, Dmytro

Dmytro, Thank you for your reply, and sorry for my late reply. I was successful in changing the MAC address of the device. Although I have questioned if I changed the correct two bytes in the ART data to create the correct CRC. I am going to copy the guide that I created in effort to help me remember if I have to do this again in the future, I hope it will be of some help to someone who encounters this same problem later.
As far as the buc_crc variable, if it is deleted from the enviornment, U-Boot recreates it upon startup. Therefore I don't need to recalculate this one, however, the ART CRC calculation is required. The ART data CRC must equal 0xffff upon the Atheros driver reading the data. There are two discrete data places in the flash, one for 2.4Ghz, and one for 5.8Ghz, each has its own data and CRC, which are outlined below.
I thank you again for your help previously, as I would not have been able to reload the FLASH without the RAM loadable software you provided.
However, the two versions provided each has some issues, but together I was able to reload the device.
The first revision was able to erase the FLASH correctly, and the ethernet initialized correctly, however, there was no "cp" command to copy from RAM to FLASH. The second revision had the "cp" instruction and could write to the FLASH (at least the upper area where the bootloader was stored), however, ethernet did not function, and it could not erase the FLASH correctly. I would like to recompile a fully working RAM loadable U-Boot incase problems arise the the future, but am not sure what you changed between the two versions, so if you could share that, I would be happy, or share how to change the ethernet type, FLASH type, etc.
Below if a copy of the guide I created to change the MAC address stored in the ART partition, and while I am not sure I edited the correct two bytes to correct the CRC, it does function, and there seem to be no side effects.
Thanks, Allan
BUFFALO WZR-HP-AG300H ***In order to change the MAC address of the wireless, we need to edit the ***FLASH where the "ART (Atheros Radio Test)" data is stored.
***This data is at address 0xbf050000 and runs to 0xbf05ffff ***however, it does not use the whole area ***the 2.4ghz information is from 0xbf051000 to 0xbf051fff ***the 5.8ghz information is from 0xbf055000 to 0xbf055fff
***the MAC address for 2.4ghz is stored at 0xbf05120c (3 bytes) ***the MAC address for 5.8ghz is stored at 0xbf05520c (3 bytes)
***this is an example of the two ethernet addresses and where they are stored 0005120c 106f3f0e5b3c 0005520c 106f3f0e5b3d
***we can't directly edit bytes in the flash since an entire page has to be ***erased and written at a time... therefore we copy the data to DRAM ***edit it, then erase the flash area and rewrite it
***copy a flash sector out so we can edit it cp.b 0xbf050000 0x84000000 0x10000
***display the current 2.4ghz ethernet address md 0x84001200 ***edit the 2.4ghz ethernet address (edits the last two bytes) ***end the write command with a "." and enter mm.b 0x84001210
***display the current 5.8ghz ethernet address md 0x84005200 ***edit the 5.8ghz ethernet address (edits the last two bytes) mm.b 0x84005210
***we need to recalculate the CRC, or the Atheros driver will not load ***in order to do this, erase the current CRC bytes (two bytes)
***so, reset the following bytes to "ff"
***2.4ghz CRC bytes mm.b 0x84001202
***5.8ghz CRC bytes mm.b 0x84005202
***write the sector back into flash protect off 0xbf050000 0xbf05ffff erase 0xbf050000 0xbf05ffff cp.b 0x84000000 0xbf050000 0x10000 protect on 0xbf050000 0xbf05ffff
***display the updated information in flash md 0xbf050000 md 0xbf051200 md 0xbf055200
***reboot the board and let dd-wrt load, a failed EEPROM CRC error can be ***ignored for now, we can fix that later, use CTRL+C to exit the error ***then use "boot" to load dd-wrt
***then, when dd-wrt loads, login and do a "dmesg | grep ath:" and ***the failed CRC value will be displayed, make note of these two bytes ***we will write them into FLASH to make the CRC calculation of 0xffff ***come out corrently
***use the following commands to once again rewrite the ART area of the FLASH ***copy a flash sector out so we can edit it
cp.b 0xbf050000 0x84000000 0x10000 ***2.4ghz CRC bytes mm.b 0x84001202
***5.8ghz CRC bytes mm.b 0x84005202
***write the sector back into flash protect off 0xbf050000 0xbf05ffff erase 0xbf050000 0xbf05ffff cp.b 0x84000000 0xbf050000 0x10000 protect on 0xbf050000 0xbf05ffff
***to fix the EEPROM CRC failed error, erase the CRC enviornment variable ***it will be recreated on next reboot setenv buf_crc saveenv reset
________________________________________ From: Dmytro [dioptimizer@gmail.com] Sent: Friday, December 14, 2012 15:31 To: Drassal, Allan Cc: U-Boot Mailing List Subject: Re: Atheros "ART" data crc calculation
Hello again Allan, Can you on work device (with correct ART section and with no checksum error), enter the u-boot command - "printenv" ? Also would you please share your ART section of the same device?
Idea is this, it is necessary to calculate the checksum of ART section (only not clearly what part of the calculate, with empty sectors "FF" or workspace) in CRC32 format, then correct this checksum in "buf_crc" environment variable.
https://forum.openwrt.org/viewtopic.php?pid=153580#p153580
Best regards, Dmytro

Made a slight correction on which bytes to change to 0xff for the CRC calculation for the ART data.
BUFFALO WZR-HP-AG300H ***In order to change the MAC address of the wireless, we need to edit the ***FLASH where the "ART (Atheros Radio Test)" data is stored.
***This data is at address 0xbf050000 and runs to 0xbf05ffff ***however, it does not use the whole area ***the 2.4ghz information is from 0xbf051000 to 0xbf051fff ***the 5.8ghz information is from 0xbf055000 to 0xbf055fff
***the MAC address for 2.4ghz is stored at 0xbf05120c (3 bytes) ***the MAC address for 5.8ghz is stored at 0xbf05520c (3 bytes)
***this is an example of the two ethernet addresses and where they are stored 0005120c 106f3f0e5b3c 0005520c 106f3f0e5b3d
***we can't directly edit bytes in the flash since an entire page has to be ***erased and written at a time... therefore we copy the data to DRAM ***edit it, then erase the flash area and rewrite it
***copy a flash sector out so we can edit it cp.b 0xbf050000 0x84000000 0x10000
***display the current 2.4ghz ethernet address md 0x84001200 ***edit the 2.4ghz ethernet address (edits the last two bytes) ***end the write command with a "." and enter mm.b 0x84001210
***display the current 5.8ghz ethernet address md 0x84005200 ***edit the 5.8ghz ethernet address (edits the last two bytes) mm.b 0x84005210
***we need to recalculate the CRC, or the Atheros driver will not load ***in order to do this, erase the current CRC bytes (two bytes)
***so, reset the following four bytes (two bytes for 2.4Ghz and two bytes for 5.8Ghz) to "ff"
***2.4ghz CRC bytes (two bytes starting at the following address) mm.b 0x84001202 ***set them to 0xff and 0xff
***5.8ghz CRC bytes (two bytes starting at the following address) mm.b 0x84005202 ***set them to 0xff and 0xff
***write the sector back into flash protect off 0xbf050000 0xbf05ffff erase 0xbf050000 0xbf05ffff cp.b 0x84000000 0xbf050000 0x10000 protect on 0xbf050000 0xbf05ffff
***display the updated information in flash md 0xbf050000 md 0xbf051200 md 0xbf055200
***reboot the board and let dd-wrt load, a failed EEPROM CRC error can be ***ignored for now, we can fix that later, use CTRL+C to exit the error ***then use "boot" to load dd-wrt
***then, when dd-wrt loads, login and do a "dmesg | grep ath:" and ***the failed CRC value will be displayed, make note of these two bytes ***we will write them into FLASH to make the CRC calculation of 0xffff ***come out corrently
***use the following commands to once again rewrite the ART area of the FLASH ***copy a flash sector out so we can edit it
cp.b 0xbf050000 0x84000000 0x10000 ***2.4ghz CRC bytes mm.b 0x84001202
***5.8ghz CRC bytes mm.b 0x84005202
***write the sector back into flash protect off 0xbf050000 0xbf05ffff erase 0xbf050000 0xbf05ffff cp.b 0x84000000 0xbf050000 0x10000 protect on 0xbf050000 0xbf05ffff
***to fix the EEPROM CRC failed error, erase the CRC enviornment variable ***it will be recreated on next reboot setenv buf_crc saveenv reset
________________________________________ From: Dmytro [dioptimizer@gmail.com] Sent: Friday, December 14, 2012 15:31 To: Drassal, Allan Cc: U-Boot Mailing List Subject: Re: Atheros "ART" data crc calculation
Hello again Allan, Can you on work device (with correct ART section and with no checksum error), enter the u-boot command - "printenv" ? Also would you please share your ART section of the same device?
Idea is this, it is necessary to calculate the checksum of ART section (only not clearly what part of the calculate, with empty sectors "FF" or workspace) in CRC32 format, then correct this checksum in "buf_crc" environment variable.
https://forum.openwrt.org/viewtopic.php?pid=153580#p153580
Best regards, Dmytro

Hello, I'm glad that all was resolved!
However, the two versions provided each has some issues, but together I was able to reload the device.
The first revision was able to erase the FLASH correctly, and the ethernet initialized correctly, however, there was no "cp" command to copy from RAM to FLASH. The second revision had the "cp" instruction and could write to the FLASH (at least the upper area where the bootloader was stored), however, ethernet did not function, and it could not erase the FLASH correctly. I would like to recompile a fully working RAM loadable U-Boot incase problems arise the the future, but am not sure what you changed between the two versions, so if you could share that, I would be happy, or share how to change the ethernet type, FLASH type, etc.
The main changes to load from the memory implemented in this patch: http://dioptimizer.narod.ru/files/ap96/path.diff When you have a problem with uboot command "flinfo", this patch may fix this problem: http://dioptimizer.narod.ru/files/ap96/path2.diff
GPL Used: http://www.tp-link.com/resources/GPL/mr3420_3220v1.tar.gz You can use any other GPL (but only with the support configuration ap96). For example, I use a specific GPL, since there is no need to compile a new version of toolchain.
However, you should understand that the configuration of the flash memory is set in ap96/boot/u-boot/include/configs/ap96.h. And detect the size of flash memory on SPI is nowhere realized. The commands used in uboot console set in parameter: CONFIG_COMMANDS ((.... When using the RAM loader - need to disable all the commands that depend on the environment variables on flash.
I do not know the full configuration of your device and do not have no possibility to experiment with the settings.
Concerning the second bank of flash memory: Recently asked on the OpenWRT forum about the use of two chips of flash memory on the device with the processor AR7241. https://forum.openwrt.org/viewtopic.php?id=41019
http://svn.dd-wrt.com:8000/browser/src/linux/pb42/linux-2.6.34.6/drivers/mtd... On the same example need to patch ap96/boot/u-boot/board/ar7100/common/ar7100_flash.h
P.S. And I would like to clarify about the bootloader on Compex devices: http://wiki.openwrt.org/doc/techref/bootloader/myloader#myloram
There is need to load the bootloader in the memory at address 0x81F00000 On my device (AR7241) bootloader is loaded, !!!but at boot time it erased firmware workspace on flash memory!!! and by the way, it correctly determined the flash memory size.
Best regards, Dmytro

Hi,
We need your help on this question, we had the same problem, did you figure out how the CRC was calculated to the device? This is very important.
Can you help me on this?
-- View this message in context: http://u-boot.10912.n7.nabble.com/Re-Atheros-ART-data-crc-calculation-tp1430... Sent from the U-Boot mailing list archive at Nabble.com.
participants (3)
-
Dmytro
-
Drassal, Allan
-
filzek