From patchwork Wed Nov 21 07:49:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Cross X-Patchwork-Id: 1001159 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=flashrom.org (client-ip=80.81.252.135; helo=mail.coreboot.org; envelope-from=flashrom-bounces@flashrom.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=xobs.io Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=xobs.io header.i=@xobs.io header.b="In/+2qM4"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="ozbFGHl6"; dkim-atps=neutral Received: from mail.coreboot.org (mail.coreboot.org [80.81.252.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 430NqK1qV7z9s3C for ; Thu, 22 Nov 2018 00:35:08 +1100 (AEDT) Received: from [127.0.0.1] (helo=ra.coreboot.org) by mail.coreboot.org with esmtp (Exim 4.88) (envelope-from ) id 1gPScj-0003ia-Fn; Wed, 21 Nov 2018 14:32:57 +0100 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by mail.coreboot.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1gPNFT-0000xs-MO for flashrom@flashrom.org; Wed, 21 Nov 2018 08:48:48 +0100 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9464822070 for ; Wed, 21 Nov 2018 02:49:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 21 Nov 2018 02:49:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xobs.io; h=from :to:subject:date:message-id:reply-to:mime-version:content-type :content-transfer-encoding; s=fm1; bh=jPk9JH4BYiEutP5CRCWCpYxerl 2xLU52VjRcn+FvPwk=; b=In/+2qM4u0bdm7f1CAFkRPRBQ+mAs6cXb5savTTrT7 w5D2Xw4sjGCp57RjCYb8Wwn06rPAU6ujT06wAbEX9bSEzPXve2grPm7sEgCQU9zl JKsOkmCB1eL6VF1X39pACZtQVAAfB/DsULNnLcaRK4GURUVYz3/2vDT4dfbB8zr9 xbpLFHhXmDE3JC/B6X/kojnobm2Ur1b6tJvE/IYBGEMkBqaGKa5BBlvrpFXE7fAH QB+u+loXjRGFaVb31s6YxBRsfdH9PUR9Z2KtBhSHDIkVsD9usFgtx+tPEFzfoUCv Tw2BqvWsohAbLdx9DdQ1xN+2dZd2kXSkCJsXH1YG+p0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:reply-to:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=jPk9JH4BYiEutP5CRCWCpYxerl2xLU52VjRcn+FvPwk=; b=ozbFGHl6 1CxITvYIHyjJTfm1dbu0wV70CgyIfpbtUyFpwhOOnjqfl6Zw6SGXea6blNmfHeC/ WguSyamsQ7hTwZh93LwN/zeOZVgjwbDzoHGOiC/knwItt+ShnyQXM8N+4wTn5uDl C6N/yr8fmcCAHgxL3HlogwKp2mWlMmjseQpauD7/RUff11zZOvDaj0yObtYcA3JL xRANoWwYImZld4RNdZfKK0zg98zaN0qsOYcpCanoPK/9SWQXrwO8Q+VOENa2sliy /j0sa3X44aGwo5xqeT1fS7dKXyLnG4AeIGQBwnVREpHqDxrJVII2fDuBMtMcqW7G 0ZOeyoRQ0qsTlA== X-ME-Sender: X-ME-Proxy: Received: from [10.0.245.239] (unknown [132.147.66.42]) by mail.messagingengine.com (Postfix) with ESMTPA id 436B1E4307 for ; Wed, 21 Nov 2018 02:49:03 -0500 (EST) From: "Sean Cross" To: flashrom@flashrom.org Date: Wed, 21 Nov 2018 07:49:01 +0000 Message-Id: User-Agent: eM_Client/7.1.33325.0 Mime-Version: 1.0 X-Spam-Score: -5.8 (-----) X-Mailman-Approved-At: Wed, 21 Nov 2018 14:32:55 +0100 Subject: [flashrom] Raspberry Pi spidev failure X-BeenThere: flashrom@flashrom.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: flashrom discussion and development mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Sean Cross Errors-To: flashrom-bounces@flashrom.org Sender: "flashrom" X-Duff: Orig. Duff, Duff Lite, Duff Dry, Duff Dark, Raspberry Duff, Lady Duff, Red Duff, Tartar Control Duff Hi, I got this email from a mailing list somewhere. I'm experiencing an issue where I'm unable to flash using spidev on a Raspberry Pi. I'm running "4.14.79-1.rpi.fc27.armv7hl", which is based on Fedberry. I'm experiencing two issues: 1) I'm completely unable to access any SPI chips. This appears to be due to a bug in the kernel driver, which always yanks the CS line high despite the cs_change set to 0. A workaround I've come up with is to do everything as a single transaction, which seems to fix the problem on my device: @@ -203,15 +201,14 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, /* Just submit the first (write) request in case there is nothing to read. Otherwise submit both requests. */ - if (readcnt == 0) - iocontrol_code = SPI_IOC_MESSAGE(1); - else - iocontrol_code = SPI_IOC_MESSAGE(2); + iocontrol_code = SPI_IOC_MESSAGE(1); if (ioctl(fd, iocontrol_code, msg) == -1) { msg_cerr("%s: ioctl: %s\n", __func__, strerror(errno)); return -1; } + + memcpy(rxbuf, tmp_buf + writecnt, readcnt); return 0; } ------------------- 2) The other issue is that my device appears to want SPI_MODE_1. When I set SPI_MODE_1, it is able to detect and program the board, but fails to verify. The image that gets loaded still works, but I'm unsure of what's causing the issue. I can do some more debugging, but changing SPI_MODE_1 and applying the above-mentioned patch solves the issue for me. Sean diff --git a/linux_spi.c b/linux_spi.c index 3e60492..50f8220 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -183,14 +183,12 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned char *rxbuf) { int iocontrol_code; + char tmp_buf[readcnt + writecnt]; struct spi_ioc_transfer msg[2] = { { .tx_buf = (uint64_t)(uintptr_t)txbuf, - .len = writecnt, - }, - { - .rx_buf = (uint64_t)(uintptr_t)rxbuf, - .len = readcnt, + .rx_buf = (uint64_t)(uintptr_t)tmp_buf, + .len = writecnt+readcnt, }, };