From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752625AbbKPP1k (ORCPT ); Mon, 16 Nov 2015 10:27:40 -0500 Received: from wolverine02.qualcomm.com ([199.106.114.251]:26525 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751689AbbKPP1h (ORCPT ); Mon, 16 Nov 2015 10:27:37 -0500 X-IronPort-AV: E=McAfee;i="5700,7163,7986"; a="243160420" X-IronPort-AV: E=Sophos;i="5.20,303,1444719600"; d="scan'208";a="617780514" From: Kalle Valo To: CC: , Subject: Re: Matching crc32 checksums from kernel and user space References: <87lh9y1520.fsf@kamboji.qca.qualcomm.com> Date: Mon, 16 Nov 2015 17:27:21 +0200 In-Reply-To: <87lh9y1520.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message of "Mon, 16 Nov 2015 14:50:47 +0200") Message-ID: <87egfq0xt2.fsf@kamboji.qca.qualcomm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To euamsexm01a.eu.qualcomm.com (10.251.127.40) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kalle Valo writes: > Hi, > > I want ath10k to print a checksum for the firmware image and include > that to the firmware crash dump file as well. Then I want to print the > same checksum from user space scripts and verify it with the crash dump > file. > > I thought that crc32 would be good enough for me but it wasn't that > simple as I can't seem to getting matching checksums, at least not with > the user space tools I found. For a test case I created a simple file: > > $ xxd /lib/firmware/ath10k/crc-test.bin > 00000000: 3132 3334 3536 3738 3930 0a 1234567890. > > In kernel I get these checksums: > > [ 574.867724] crc32_le(0) 8916bc26 > [ 574.867739] crc32_le(~0) 1d6ef235 > [ 574.867743] crc32_be(0) b9346a4c > [ 574.867746] crc32_be(~0) 71467465 > > And from python I got (value in parenthesis is the seed I used): > > binascii.crc32(00000000) 0xe2910dcaL > binascii.crc32(ffffffff) 0x76e943d9L Johannes Berg pointed out that this looks to be a sign issue, I just need to invert the python value and then I get the same value: >>> hex(~0x76e943d9 & 0xffffffff) '0x8916bc26' -- Kalle Valo