From owner-freebsd-embedded@FreeBSD.ORG Mon Nov 11 11:06:47 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4EF6D8FF for ; Mon, 11 Nov 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 379BA2CAB for ; Mon, 11 Nov 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rABB6lwK081985 for ; Mon, 11 Nov 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rABB6kP1081983 for freebsd-embedded@FreeBSD.org; Mon, 11 Nov 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Nov 2013 11:06:46 GMT Message-Id: <201311111106.rABB6kP1081983@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:45 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39CBA4C3; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00E9225C8; Wed, 13 Nov 2013 22:32:44 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id A4EEE9B28; Wed, 13 Nov 2013 23:32:43 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 964AC415E; Wed, 13 Nov 2013 23:32:42 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: Re: Incorrect struct onfi_params definition Date: Wed, 13 Nov 2013 23:32:35 +0100 Message-Id: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1383782353.31172.183.camel@revolution.hippie.lan> References: <1383782353.31172.183.camel@revolution.hippie.lan> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:45 -0000 Hi Ian, Here's my attempt at a cleaned up patch series. It doesn't include the delay modifications from your nand2.diff, as that didn't actually work for me. On my OpenRD is appears that the time tick is started after the NAND initialisation, leading to infinite delays. Regards, Kristof From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:45 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E38A4C9; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1491725CA; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id BD0789B2A; Wed, 13 Nov 2013 23:32:43 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id DAAB14161; Wed, 13 Nov 2013 23:32:42 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: [PATCH 3/5] Check ONFI parameter page before using it. Date: Wed, 13 Nov 2013 23:32:38 +0100 Message-Id: <1384381960-98851-4-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:45 -0000 From: Kristof Provost The ONFI spec states that at least two bytes of the signature ("ONFI") must be present, and the CRC must be correct to have a valid parameter page. If the page is not valid there are at least two backup pages where the data can also be found. --- sys/dev/nand/nand_generic.c | 55 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 46 insertions(+), 9 deletions(-) diff --git a/sys/dev/nand/nand_generic.c b/sys/dev/nand/nand_generic.c index 2e78ab6..4ee8fdc 100644 --- a/sys/dev/nand/nand_generic.c +++ b/sys/dev/nand/nand_generic.c @@ -319,10 +319,31 @@ check_fail(device_t nandbus) return (0); } +static uint16_t +onfi_crc(const void *buf, size_t buflen) +{ + int i, j; + uint16_t crc; + const uint8_t *bufptr; + + bufptr = buf; + crc = 0x4f4e; + for (j = 0; j < buflen; j++) { + crc ^= *bufptr++ << 8; + for (i = 0; i < 8; i++) + if (crc & 0x8000) + crc = (crc << 1) ^ 0x8005; + else + crc <<= 1; + } + return crc; +} + static int onfi_read_parameter(struct nand_chip *chip, struct onfi_params *params) { device_t nandbus; + int found, sigcount, trycopy; nand_debug(NDBG_GEN,"read parameter"); @@ -339,16 +360,32 @@ onfi_read_parameter(struct nand_chip *chip, struct onfi_params *params) if (NANDBUS_START_COMMAND(nandbus)) return (ENXIO); - NANDBUS_READ_BUFFER(nandbus, params, sizeof(struct onfi_params)); - - if (memcmp(params->signature, "ONFI", sizeof(params->signature))) { - device_printf(chip->dev, "Error: bad signature\n"); - return (ENXIO); + /* + * XXX Bogus DELAY, we really need a nandbus_wait_ready() here, but it's + * not accessible from here (static to nandbus). + */ + DELAY(1000); + + /* + * The ONFI spec mandates a minimum of three copies of the parameter + * data, so loop up to 3 times trying to find good data. Each copy is + * validated by a signature of "ONFI" and a crc. There is a very strange + * rule that the signature is valid if any 2 of the 4 bytes are correct. + */ + for (found= 0, trycopy = 0; !found && trycopy < 3; trycopy++) { + NANDBUS_READ_BUFFER(nandbus, params, sizeof(struct onfi_params)); + sigcount = params->signature[0] == 'O'; + sigcount += params->signature[1] == 'N'; + sigcount += params->signature[2] == 'F'; + sigcount += params->signature[3] == 'I'; + if (sigcount < 2) + continue; + if (onfi_crc(params, 254) != params->crc) + continue; + found = 1; } - - /* TODO */ - /* Check CRC */ - /* Use redundant page if necessary */ + if (!found) + return (ENXIO); return (0); } -- 1.7.10.3 From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:45 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7C5F4D1; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5725225CC; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id D567F9B2D; Wed, 13 Nov 2013 23:32:43 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 132934162; Wed, 13 Nov 2013 23:32:43 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: [PATCH 4/5] Unpack (align) and decode (endian) the values in the onfi_params struct. Date: Wed, 13 Nov 2013 23:32:39 +0100 Message-Id: <1384381960-98851-5-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:45 -0000 From: Kristof Provost ONFI parameters are little-endian, hence we must take care to convert them to native endianness. We must also pay attention to unalligned accesses. Copy the interesting parameters to a new struct so the rest of the code can forget about these problems. --- sys/dev/nand/nand.c | 2 +- sys/dev/nand/nand.h | 16 +++++++++++++- sys/dev/nand/nand_generic.c | 51 +++++++++++++++++++++++++++---------------- 3 files changed, 48 insertions(+), 21 deletions(-) diff --git a/sys/dev/nand/nand.c b/sys/dev/nand/nand.c index f46d0f0..902ff79 100644 --- a/sys/dev/nand/nand.c +++ b/sys/dev/nand/nand.c @@ -115,7 +115,7 @@ nand_init(struct nand_softc *nand, device_t dev, int ecc_mode, } void -nand_onfi_set_params(struct nand_chip *chip, struct onfi_params *params) +nand_onfi_set_params(struct nand_chip *chip, struct onfi_chip_params *params) { struct chip_geom *cg; diff --git a/sys/dev/nand/nand.h b/sys/dev/nand/nand.h index d9bfad7..4fbe75c 100644 --- a/sys/dev/nand/nand.h +++ b/sys/dev/nand/nand.h @@ -235,6 +235,20 @@ struct onfi_params { }__attribute__((packed)); CTASSERT(sizeof(struct onfi_params) == 256); +struct onfi_chip_params { + uint8_t luns; + uint32_t blocks_per_lun; + uint32_t pages_per_block; + uint32_t bytes_per_page; + uint32_t spare_bytes_per_page; + uint16_t t_bers; + uint16_t t_prog; + uint16_t t_r; + uint16_t t_ccs; + uint16_t features; + uint8_t address_cycles; +}; + struct nand_ecc_data { int eccsize; /* Number of data bytes per ECC step */ int eccmode; @@ -367,7 +381,7 @@ void nand_init(struct nand_softc *nand, device_t dev, int ecc_mode, void nand_detach(struct nand_softc *nand); struct nand_params *nand_get_params(struct nand_id *id); -void nand_onfi_set_params(struct nand_chip *chip, struct onfi_params *params); +void nand_onfi_set_params(struct nand_chip *chip, struct onfi_chip_params *params); void nand_set_params(struct nand_chip *chip, struct nand_params *params); int nand_init_stat(struct nand_chip *chip); void nand_destroy_stat(struct nand_chip *chip); diff --git a/sys/dev/nand/nand_generic.c b/sys/dev/nand/nand_generic.c index 4ee8fdc..62c6161 100644 --- a/sys/dev/nand/nand_generic.c +++ b/sys/dev/nand/nand_generic.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -73,7 +74,7 @@ static int small_program_page(device_t, uint32_t, void *, uint32_t, uint32_t); static int small_program_oob(device_t, uint32_t, void *, uint32_t, uint32_t); static int onfi_is_blk_bad(device_t, uint32_t, uint8_t *); -static int onfi_read_parameter(struct nand_chip *, struct onfi_params *); +static int onfi_read_parameter(struct nand_chip *, struct onfi_chip_params *); static int nand_send_address(device_t, int32_t, int32_t, int8_t); @@ -206,7 +207,7 @@ generic_nand_attach(device_t dev) { struct nand_chip *chip; struct nandbus_ivar *ivar; - struct onfi_params *onfi_params; + struct onfi_chip_params *onfi_chip_params; device_t nandbus, nfc; int err; @@ -225,25 +226,24 @@ generic_nand_attach(device_t dev) chip->nand = device_get_softc(nfc); if (ivar->is_onfi) { - onfi_params = malloc(sizeof(struct onfi_params), + onfi_chip_params = malloc(sizeof(struct onfi_chip_params), M_NAND, M_WAITOK | M_ZERO); - if (onfi_params == NULL) - return (ENXIO); + if (onfi_chip_params == NULL) + return (ENOMEM); - if (onfi_read_parameter(chip, onfi_params)) { + if (onfi_read_parameter(chip, onfi_chip_params)) { nand_debug(NDBG_GEN,"Could not read parameter page!\n"); - free(onfi_params, M_NAND); + free(onfi_chip_params, M_NAND); return (ENXIO); } - nand_onfi_set_params(chip, onfi_params); + nand_onfi_set_params(chip, onfi_chip_params); /* Set proper column and row cycles */ - ivar->cols = (onfi_params->address_cycles >> 4) & 0xf; - ivar->rows = onfi_params->address_cycles & 0xf; - free(onfi_params, M_NAND); + ivar->cols = (onfi_chip_params->address_cycles >> 4) & 0xf; + ivar->rows = onfi_chip_params->address_cycles & 0xf; + free(onfi_chip_params, M_NAND); } else { - nand_set_params(chip, ivar->params); } @@ -340,9 +340,10 @@ onfi_crc(const void *buf, size_t buflen) } static int -onfi_read_parameter(struct nand_chip *chip, struct onfi_params *params) +onfi_read_parameter(struct nand_chip *chip, struct onfi_chip_params *chip_params) { device_t nandbus; + struct onfi_params params; int found, sigcount, trycopy; nand_debug(NDBG_GEN,"read parameter"); @@ -373,20 +374,32 @@ onfi_read_parameter(struct nand_chip *chip, struct onfi_params *params) * rule that the signature is valid if any 2 of the 4 bytes are correct. */ for (found= 0, trycopy = 0; !found && trycopy < 3; trycopy++) { - NANDBUS_READ_BUFFER(nandbus, params, sizeof(struct onfi_params)); - sigcount = params->signature[0] == 'O'; - sigcount += params->signature[1] == 'N'; - sigcount += params->signature[2] == 'F'; - sigcount += params->signature[3] == 'I'; + NANDBUS_READ_BUFFER(nandbus, ¶ms, sizeof(struct onfi_params)); + sigcount = params.signature[0] == 'O'; + sigcount += params.signature[1] == 'N'; + sigcount += params.signature[2] == 'F'; + sigcount += params.signature[3] == 'I'; if (sigcount < 2) continue; - if (onfi_crc(params, 254) != params->crc) + if (onfi_crc(¶ms, 254) != params.crc) continue; found = 1; } if (!found) return (ENXIO); + chip_params->luns = params.luns; + chip_params->blocks_per_lun = le32dec(¶ms.blocks_per_lun); + chip_params->pages_per_block = le32dec(¶ms.pages_per_block); + chip_params->bytes_per_page = le32dec(¶ms.bytes_per_page); + chip_params->spare_bytes_per_page = le32dec(¶ms.spare_bytes_per_page); + chip_params->t_bers = le16dec(¶ms.t_bers); + chip_params->t_prog = le16dec(¶ms.t_prog); + chip_params->t_r = le16dec(¶ms.t_r); + chip_params->t_ccs = le16dec(¶ms.t_ccs); + chip_params->features = le16dec(¶ms.features); + chip_params->address_cycles = params.address_cycles; + return (0); } -- 1.7.10.3 From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:45 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ECAB4C6; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 05C2525C9; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id B1CF39B29; Wed, 13 Nov 2013 23:32:43 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id BA2B1415F; Wed, 13 Nov 2013 23:32:42 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: [PATCH 1/5] Fix typo in struct onfi_params Date: Wed, 13 Nov 2013 23:32:36 +0100 Message-Id: <1384381960-98851-2-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:45 -0000 From: Kristof Provost The vendor specified field is 88 bytes, not 8 bytes. See ONFI specification rev. 2.3a: 5.7.1 Parameter Page Data Structure Definition --- sys/dev/nand/nand.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sys/dev/nand/nand.h b/sys/dev/nand/nand.h index d2aa661..1ca0fb2 100644 --- a/sys/dev/nand/nand.h +++ b/sys/dev/nand/nand.h @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -218,9 +219,10 @@ struct onfi_params { uint8_t driver_strength_support; uint8_t res4[12]; uint16_t vendor_rev; - uint8_t vendor_spec[8]; + uint8_t vendor_spec[88]; uint16_t crc; }__attribute__((packed)); +CTASSERT(sizeof(struct onfi_params) == 256); struct nand_ecc_data { int eccsize; /* Number of data bytes per ECC step */ -- 1.7.10.3 From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:46 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA0EF4D6; Wed, 13 Nov 2013 22:32:46 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD2BB25CD; Wed, 13 Nov 2013 22:32:46 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id 5329B9B2F; Wed, 13 Nov 2013 23:32:44 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 3E8A34163; Wed, 13 Nov 2013 23:32:43 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: [PATCH 5/5] Rework the routine that returns a pointer to the table of software ECC byte positions within the OOB area to support chips with unusual OOB sizes such as 218 or 224 bytes (the table for 128 byte OOB works for these but it assumes 3 bytes of ECC per 256 byte block, and in the case of an ONFI chip the params page may ask for something different). Date: Wed, 13 Nov 2013 23:32:40 +0100 Message-Id: <1384381960-98851-6-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:47 -0000 From: Kristof Provost --- sys/dev/nand/nand.c | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/sys/dev/nand/nand.c b/sys/dev/nand/nand.c index 902ff79..fb83e67 100644 --- a/sys/dev/nand/nand.c +++ b/sys/dev/nand/nand.c @@ -309,23 +309,22 @@ nand_get_chip_param(struct nand_chip *chip, struct chip_param_io *param) static uint16_t * default_software_ecc_positions(struct nand_chip *chip) { - struct nand_ecc_data *eccd; - - eccd = &chip->nand->ecc; - - if (eccd->eccpositions) - return (eccd->eccpositions); - - switch (chip->chip_geom.oob_size) { - case 16: - return ((uint16_t *)&default_software_ecc_positions_16); - case 64: - return ((uint16_t *)&default_software_ecc_positions_64); - case 128: - return ((uint16_t *)&default_software_ecc_positions_128); - default: - return (NULL); /* No ecc bytes positions defs available */ - } + /* If positions have been set already, use them. */ + if (chip->nand->ecc.eccpositions) + return (chip->nand->ecc.eccpositions); + + /* + * XXX Note that the following logic isn't really sufficient, especially + * in the ONFI case where the number of ECC bytes can be dictated by + * values in the parameters page, and that could lead to needing more + * byte positions than exist within the tables of software-ecc defaults. + */ + if (chip->chip_geom.oob_size >= 128) + return (default_software_ecc_positions_128); + if (chip->chip_geom.oob_size >= 64) + return (default_software_ecc_positions_64); + else if (chip->chip_geom.oob_size >= 16) + return (default_software_ecc_positions_16); return (NULL); } -- 1.7.10.3 From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 13 22:32:45 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E8344CA; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14D4D25CB; Wed, 13 Nov 2013 22:32:45 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (unknown [IPv6:2a02:1811:2000:701:1b:9fff:fe00:160b]) by venus.codepro.be (Postfix) with ESMTPSA id BDB509B2C; Wed, 13 Nov 2013 23:32:43 +0100 (CET) Received: from sigsegv.be (unknown [10.0.2.251]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id CD23D4160; Wed, 13 Nov 2013 23:32:42 +0100 (CET) From: kristof@sigsegv.be To: Ian Lepore Subject: [PATCH 2/5] Update the fields in the onfi_params struct to reflect standards updates. Date: Wed, 13 Nov 2013 23:32:37 +0100 Message-Id: <1384381960-98851-3-git-send-email-kristof@sigsegv.be> X-Mailer: git-send-email 1.7.10.3 In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:32:45 -0000 From: Kristof Provost Update to ONFI revision 3.2 (06 12 2013). http://www.onfi.org/~/media/ONFI/specs/ONFI_3_2%20Gold.pdf --- sys/dev/nand/nand.h | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/sys/dev/nand/nand.h b/sys/dev/nand/nand.h index 1ca0fb2..d9bfad7 100644 --- a/sys/dev/nand/nand.h +++ b/sys/dev/nand/nand.h @@ -178,12 +178,17 @@ struct onfi_params { uint16_t rev; uint16_t features; uint16_t optional_commands; - uint8_t res1[22]; + uint8_t primary_advanced_command; + uint8_t res1; + uint16_t extended_parameter_page_length; + uint8_t parameter_page_count; + uint8_t res2[17]; char manufacturer_name[12]; char device_model[20]; uint8_t manufacturer_id; - uint16_t date; - uint8_t res2[13]; + uint8_t manufacture_date_yy; + uint8_t manufacture_date_ww; + uint8_t res3[13]; uint32_t bytes_per_page; uint16_t spare_bytes_per_page; uint32_t bytes_per_partial_page; @@ -202,7 +207,8 @@ struct onfi_params { uint8_t bits_of_ecc; uint8_t interleaved_addr_bits; uint8_t interleaved_oper_attr; - uint8_t res3[13]; + uint8_t eznand_support; + uint8_t res4[12]; uint8_t pin_capacitance; uint16_t asynch_timing_mode_support; uint16_t asynch_prog_cache_timing_mode_support; @@ -217,7 +223,12 @@ struct onfi_params { uint16_t input_capacitance; uint8_t input_capacitance_max; uint8_t driver_strength_support; - uint8_t res4[12]; + uint16_t t_r_interleaved; + uint16_t t_adl; + uint16_t t_r_eznand; + uint8_t nv_ddr2_features; + uint8_t nv_ddr2_warmup_cycles; + uint8_t res5[4]; uint16_t vendor_rev; uint8_t vendor_spec[88]; uint16_t crc; -- 1.7.10.3 From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 17:04:42 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12DD4102; Fri, 15 Nov 2013 17:04:42 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD0062736; Fri, 15 Nov 2013 17:04:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VhMos-0005nO-9r; Fri, 15 Nov 2013 17:04:34 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAFH4VO4075085; Fri, 15 Nov 2013 10:04:31 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+zTIfNHyCjxN8Qfd3b6FwY Subject: Re: [PATCH 4/5] Unpack (align) and decode (endian) the values in the onfi_params struct. From: Ian Lepore To: kristof@sigsegv.be In-Reply-To: <1384381960-98851-5-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384381960-98851-5-git-send-email-kristof@sigsegv.be> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 2013 10:04:31 -0700 Message-ID: <1384535071.31172.381.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:04:42 -0000 On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: > From: Kristof Provost > > ONFI parameters are little-endian, hence we must take care to convert them to > native endianness. We must also pay attention to unalligned accesses. > > Copy the interesting parameters to a new struct so the rest of the code can > forget about these problems. > --- > sys/dev/nand/nand.c | 2 +- > sys/dev/nand/nand.h | 16 +++++++++++++- > sys/dev/nand/nand_generic.c | 51 +++++++++++++++++++++++++++---------------- > 3 files changed, 48 insertions(+), 21 deletions(-) > > diff --git a/sys/dev/nand/nand.c b/sys/dev/nand/nand.c > index f46d0f0..902ff79 100644 > --- a/sys/dev/nand/nand.c > +++ b/sys/dev/nand/nand.c > @@ -115,7 +115,7 @@ nand_init(struct nand_softc *nand, device_t dev, int ecc_mode, > } > > void > -nand_onfi_set_params(struct nand_chip *chip, struct onfi_params *params) > +nand_onfi_set_params(struct nand_chip *chip, struct onfi_chip_params *params) > { > struct chip_geom *cg; > > diff --git a/sys/dev/nand/nand.h b/sys/dev/nand/nand.h > index d9bfad7..4fbe75c 100644 > --- a/sys/dev/nand/nand.h > +++ b/sys/dev/nand/nand.h > @@ -235,6 +235,20 @@ struct onfi_params { > }__attribute__((packed)); > CTASSERT(sizeof(struct onfi_params) == 256); > > +struct onfi_chip_params { > + uint8_t luns; > + uint32_t blocks_per_lun; > + uint32_t pages_per_block; > + uint32_t bytes_per_page; > + uint32_t spare_bytes_per_page; > + uint16_t t_bers; > + uint16_t t_prog; > + uint16_t t_r; > + uint16_t t_ccs; > + uint16_t features; > + uint8_t address_cycles; > +}; Sorry for the delay on this, I finally got around to looking at these today. The only comment I have on the 5 patches is that if the 'luns' field of the new onfi_chip_params struct were moved to the end, the struct would be ideally packed with no unused padding on architectures where alignment counts. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 17:39:23 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CF211DF; Fri, 15 Nov 2013 17:39:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D88612991; Fri, 15 Nov 2013 17:39:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VhNMS-000K3H-DO; Fri, 15 Nov 2013 17:39:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAFHdDOY075132; Fri, 15 Nov 2013 10:39:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+3kgq9+V21qC5JqD35dOB/ Subject: Re: Incorrect struct onfi_params definition From: Ian Lepore To: kristof@sigsegv.be In-Reply-To: <1384381960-98851-1-git-send-email-kristof@sigsegv.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 2013 10:39:13 -0700 Message-ID: <1384537153.31172.398.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:39:23 -0000 On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: > Hi Ian, > > Here's my attempt at a cleaned up patch series. > > It doesn't include the delay modifications from your nand2.diff, as that > didn't actually work for me. On my OpenRD is appears that the time tick is > started after the NAND initialisation, leading to infinite delays. > I'm interested in hearing more about this. I don't quite understand what you mean by "time tick is started after...". The delay-related changes should completely remove all use of clocks or timing. What it does instead is repeatedly issue "get status" commands to the chip until the chip says it's done with the previous operation and ready to continue. The big advantage is that a DELAY(1000) will always wait a millisecond, but modern nand chips are often ready to procede after just a few microseconds. It really helped bulk data throughput. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 18:22:50 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8B3A9B4 for ; Fri, 15 Nov 2013 18:22:50 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8D622C4F for ; Fri, 15 Nov 2013 18:22:50 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id at1so5301085iec.16 for ; Fri, 15 Nov 2013 10:22:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v7gmHGniT2YLb2/hYUiPAOW7DEHLZN3TECJ9i7T5bX8=; b=iVUT/4yXIDiTZtFIabf2tXIPBVRljkBET1d/BC1xpmymMq5VK9uUqfnQcXp6EZzAS/ 56q18zQjdssXyU5oU6xN7Bw0E0f5fToC+byXFuShnsi0li82tCu0Rul8HcybHaZDsJJR Vh6JQiApfiR7tcB12rj6r/Q1MkX7h4P1hKKYnr8eP+4HDO6ZW7PxQe+EQ6+quu/zfbYW PL14kzamoFpBPrEoTgoyXklHtjKBLujYsSXwV8oHJKaUOvzrdxv6/yAJXvMeerQ7PD1H +EaZEnuzDqAHQ8Sqsm+JZVh1W8jucII4/IchnXDwWe8drY6LhHeHQ94B4Kn1LgIysxak 1CYg== X-Gm-Message-State: ALoCoQkijyMmG+6M0FqM0B8Cn6UsXgXzt5CTBWnVUe3nHssBXEUKIorRl2uBpHxvAuQh+OuPxPqL X-Received: by 10.50.73.74 with SMTP id j10mr5351489igv.50.1384539764563; Fri, 15 Nov 2013 10:22:44 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id w4sm4482047igb.5.2013.11.15.10.22.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 10:22:44 -0800 (PST) Sender: Warner Losh Subject: Re: Incorrect struct onfi_params definition Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1384537153.31172.398.camel@revolution.hippie.lan> Date: Fri, 15 Nov 2013 11:22:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73F6EE79-C4CB-4831-8DA3-6EE70931C0DA@bsdimp.com> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:22:50 -0000 On Nov 15, 2013, at 10:39 AM, Ian Lepore wrote: > On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: >> Hi Ian, >>=20 >> Here's my attempt at a cleaned up patch series. >>=20 >> It doesn't include the delay modifications from your nand2.diff, as = that >> didn't actually work for me. On my OpenRD is appears that the time = tick is >> started after the NAND initialisation, leading to infinite delays. =20= >>=20 >=20 > I'm interested in hearing more about this. I don't quite understand > what you mean by "time tick is started after...". The delay-related > changes should completely remove all use of clocks or timing. What it > does instead is repeatedly issue "get status" commands to the chip = until > the chip says it's done with the previous operation and ready to > continue. =20 >=20 > The big advantage is that a DELAY(1000) will always wait a = millisecond, > but modern nand chips are often ready to procede after just a few > microseconds. It really helped bulk data throughput. Yes. tREAD on 54nm and newer chips can be as low as 35us, but typically = you're looking at 70-100us on the 2x, 2y and 1x nm parts before the data = is ready. 1000us is definitely too long to wait, and can only be = considered very pessimal. The NAND chips will tell you when the data = buffer can be read out was well by asking them for the status, and that = needs no delays (not 100% true, but the delays are in the 10's or 100's = of ns range and usually papered over by the NAND controller). Warner From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 19:13:17 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A0FAAD; Fri, 15 Nov 2013 19:13:17 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1841D2F42; Fri, 15 Nov 2013 19:13:16 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 6FE809869; Fri, 15 Nov 2013 20:13:15 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 682D73086; Fri, 15 Nov 2013 20:13:15 +0100 (CET) Date: Fri, 15 Nov 2013 20:13:15 +0100 From: Kristof Provost To: Ian Lepore Subject: Re: Incorrect struct onfi_params definition Message-ID: <20131115191315.GF58987@vega.codepro.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1384537153.31172.398.camel@revolution.hippie.lan> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:13:17 -0000 On 2013-11-15 10:39:13 (-0700), Ian Lepore wrote: > On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: > > Hi Ian, > > > > Here's my attempt at a cleaned up patch series. > > > > It doesn't include the delay modifications from your nand2.diff, as that > > didn't actually work for me. On my OpenRD is appears that the time tick is > > started after the NAND initialisation, leading to infinite delays. > > > > I'm interested in hearing more about this. I don't quite understand > what you mean by "time tick is started after...". The delay-related > changes should completely remove all use of clocks or timing. What it > does instead is repeatedly issue "get status" commands to the chip until > the chip says it's done with the previous operation and ready to > continue. > Actually, it's probably a combination of two problems. I get a timeout while reading the parameter page, or rather, I'm supposed to get a timeout, but nandbus_wait_ready() uses getmicrotime(), which always returns 0. In effect it creates an infinite loop. The fact that there's never a NAND_STATUS_RDY after the NAND_CMD_READ_PARAMETER is interesting, but not really the point here. As I understand it getmicrotime() (at least when FFCLOCK is not defined) is not updated until after inittimecounter(), which is done after the nand initialisation. Regards, Kristof From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 19:47:54 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C2D26DA; Fri, 15 Nov 2013 19:47:54 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6276A2124; Fri, 15 Nov 2013 19:47:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VhPMv-0001dO-BP; Fri, 15 Nov 2013 19:47:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAFJlouT075245; Fri, 15 Nov 2013 12:47:50 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18r3+LV5bbLsqdp1OtBL0nd Subject: Re: Incorrect struct onfi_params definition From: Ian Lepore To: Kristof Provost In-Reply-To: <20131115191315.GF58987@vega.codepro.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan> <20131115191315.GF58987@vega.codepro.be> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 2013 12:47:50 -0700 Message-ID: <1384544870.31172.420.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:47:54 -0000 On Fri, 2013-11-15 at 20:13 +0100, Kristof Provost wrote: > On 2013-11-15 10:39:13 (-0700), Ian Lepore wrote: > > On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: > > > Hi Ian, > > > > > > Here's my attempt at a cleaned up patch series. > > > > > > It doesn't include the delay modifications from your nand2.diff, as that > > > didn't actually work for me. On my OpenRD is appears that the time tick is > > > started after the NAND initialisation, leading to infinite delays. > > > > > > > I'm interested in hearing more about this. I don't quite understand > > what you mean by "time tick is started after...". The delay-related > > changes should completely remove all use of clocks or timing. What it > > does instead is repeatedly issue "get status" commands to the chip until > > the chip says it's done with the previous operation and ready to > > continue. > > > Actually, it's probably a combination of two problems. > > I get a timeout while reading the parameter page, or rather, I'm > supposed to get a timeout, but nandbus_wait_ready() uses getmicrotime(), > which always returns 0. In effect it creates an infinite loop. > > The fact that there's never a NAND_STATUS_RDY after the > NAND_CMD_READ_PARAMETER is interesting, but not really the point here. > > As I understand it getmicrotime() (at least when FFCLOCK is not defined) > is not updated until after inittimecounter(), which is done after the > nand initialisation. Oh. Hmm, I had forgotten I put a timeout in that loop. Shame on me, I guess, for trying to base it on an actual clock instead doing the usual "count down from a number with an arbitrary number of zeroes at the end" that doesn't scale properly across the range of processor speeds we support today. :) I'll ponder a good fix (maybe keep using the clock but fall back to a counter if the clock isn't running). You're right, the real question is why you never get the ready status. The timeout logic is just a crisis fallback, because I hate drivers that lock up forever on the assumption that something "can't fail." But getting the status really shouldn't fail. Is it only the parameter-read that has this problem, or do regular reads and writes fail to get status too? Maybe there's something in the marvell nand flash interface that leads to this; I did my work on an Atmel SoC (but I do have a Dreamplug here that has nand flash on it, it's sort of a Guruplug in a Dreamplug case; not many were shipped). -- Ian