ASpeed IPMI Firmware»

I’ve started looking into adding ASpeed support to my IPMI Firmware Tools. Initially, this was pretty straightfoward. There’s a nice block at the end of the file that describes all the images present as well as their offsets. It looks like this:

01fc0000  5b 69 6d 67 5d 3a 20 30  20 32 30 66 31 38 20 39  |[img]: 0 20f18 9|
01fc0010  37 34 65 64 62 33 66 20  75 2d 62 6f 6f 74 2e 62  |74edb3f u-boot.b|
01fc0020  69 6e 5b 69 6d 67 5d 3a  20 34 30 30 30 30 30 20  |in[img]: 400000 |
01fc0030  39 34 33 30 30 30 20 39  32 66 38 61 61 30 36 20  |943000 92f8aa06 |
01fc0040  6f 75 74 5f 72 6f 6f 74  66 73 5f 69 6d 67 2e 62  |out_rootfs_img.b|
01fc0050  69 6e 5b 69 6d 67 5d 3a  20 31 34 30 30 30 30 30  |in[img]: 1400000|
01fc0060  20 31 35 39 31 34 31 20  38 36 38 38 65 62 65 32  | 159141 8688ebe2|
01fc0070  20 6f 75 74 5f 6b 65 72  6e 65 6c 2e 62 69 6e 5b  | out_kernel.bin[|
01fc0080  69 6d 67 5d 3a 20 31 37  30 30 30 30 30 20 31 64  |img]: 1700000 1d|
01fc0090  34 30 30 61 20 64 65 36  30 36 66 33 33 20 6f 75  |400a de606f33 ou|
01fc00a0  74 5f 77 65 62 66 73 5f  69 6d 67 2e 62 69 6e 5b  |t_webfs_img.bin[|
01fc00b0  65 6e 64 5d 00 00 00 00  00 00 00 00 00 00 00 00  |end]............|
01fc00c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

which parses out to this (note the image number is not part of the block):


Firmware image: 1 Name: u-boot.bin Base: 0×0 Length: 0×20f18 CRC32: 0×974edb3f
Firmware image: 2 Name: out_rootfs_img.bin Base: 0×400000 Length: 0×943000 CRC32: 0×92f8aa06
Firmware image: 3 Name: out_kernel.bin Base: 0×1400000 Length: 0×159141 CRC32: 0×8688ebe2
Firmware image: 4 Name: out_webfs_img.bin Base: 0×1700000 Length: 0×1d400a CRC32: 0xde606f33

However, there’s another footer in the file, and I don’t quite understand this one yet:

018d4000  41 54 45 4e 73 5f 46 57  01 23 39 32 66 38 39 34  |ATENs_FW.#92f894|
018d4010  33 30 71 64 65 36 30 31  64 34 30 17 ff ff ff ff  |30qde601d40.....|
018d4020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

It starts off pretty standard (ATENs_FW MAJORVER MINORVER), but from there it’s currently a mystery. The remaining content is too big to be a CRC32 or the other weird checksum algorithm that I’ve seen them use before. It’s too small to be something like a MD5, and even odder it’s not a power of two bits (it’s 68 bits). I’m suspecting that this is at least two seperate fields, but I’m not sure.

I’ve added basic support at the moment. I can extract the firmware, and verify the known checksums. There isn’t any sort of support for regenerating an image though.