From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:21:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA54998A for ; Tue, 7 Oct 2014 17:21:28 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB7316E for ; Tue, 7 Oct 2014 17:21:27 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id w10so5445267pde.0 for ; Tue, 07 Oct 2014 10:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tDNfUsmzDINKcCqY8NVEasn0r5ydOedBzipfTP80GhA=; b=NESEUXiJ+DdipIGXvV2rV6FjmXBY9Q6O+wkimWWKjhyiCiLW1M4W9K/HMKQbX/7C2k O3OUyoyJSPCODGUrSej/K20a3+bGL0w7le6Q5XqTHv1VY7rqDeUBWDcij5H6bEnpCngf mbIwRQ+tcWIId8/P7b770dsi2qnYfHcKnKk1qCjl5wB7efK3F9DQc8rByGZJitelAAPT LnS8S3R6E5xWq7V/rtj6cVgdSZClV5XmJA69FNe7ATkigVIVSs7y1W3LVuPKe5GqE+x7 1uop7i+Atj+6Kndm7vUsHfR4ggf1vyDWyKdubVqWa40c1yF/4fQ2WcwN5MMH5YzYWJSd NUAQ== X-Gm-Message-State: ALoCoQlGz/zlOFTVZkVD3HcnH40cpYNm5aK37nGs85JVAQ0GL6iCxHvyBaZkq07TXpF7hjMD4nBD X-Received: by 10.68.248.9 with SMTP id yi9mr4979371pbc.118.1412702480728; Tue, 07 Oct 2014 10:21:20 -0700 (PDT) Received: from [10.64.26.130] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id g13sm16789225pat.45.2014.10.07.10.21.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 10:21:20 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Tue, 7 Oct 2014 11:21:16 -0600 Message-Id: <2C5A1F77-C3DD-4146-9A08-93625B7B8291@bsdimp.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm , Ian Lepore , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:21:28 -0000 --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 6, 2014, at 4:11 PM, Russell Haley wrote: > Okay, that's both great and too bad. I had wondered about the > performance of ECC in software. However, it turns out one of the > Senior Engineers did his masters on ECC so I had a line on an > implementation. It wouldn=92t hurt to have a good implementation, since most of the time = they can be parameterized, but it likely is going to be on the slow side... > Anyway, I won't get to anything for a couple of days but will look > into this further on the weekend. Wow. Did I really just get sucked > into writing a NFC driver? lolz :) Warner > On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: >>=20 >> On Oct 6, 2014, at 1:35 PM, Russell Haley = wrote: >>=20 >>> I have been pinging some of the engineers here about ECC. I *might* = be >>> able to get someone to help me with a BCH implementation. The >>> recommendation was to start by checking the Linux or Android source >>> code that comes with the Jump starter Kit. I suspect however they = used >>> the build in hardware implementation but will verify that. Do you >>> want me to look at writing a BSD ECC or implement something that can >>> leverage a hardware implementation (which road should I take)? >>>=20 >>> I guess another factor would be if the iMX6 and next gen Freescale >>> stuff uses the same/similar controllers or if it's something = different >>> altogether? >>>=20 >>> Also, I was wondering how closely the CWMX53 board support has >>> followed the guidelines here: >>> https://wiki.freebsd.org/FreeBSDArmBoards? >>=20 >> I don=92t think our current 1-bit ECC is enough. The problem with = most of >> the SoCs implement strong ECC, but they are all different. They use >> different parameters for BCH to achieve the same ECC strength that >> different NAND vendors recommend. >>=20 >> You absolutely have to do this in hardware. Software ECC is too slow = by >> a factor of 10 or 100, especially as the codes get more complex (some >> recent parts require like 39 bits over 1k). 1-bit hamming code is bad = enough. >>=20 >> Ideally, we can accept a divergence of ECC in the details, and = instead allow >> for full and partial hardware offload for ECC generation and = correction. >>=20 >> Warner >>=20 >>=20 >>> On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >>>> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>>>> Alright, well night one of my crash course in C and it wasn't = quite as >>>>> painful as I thought. For shits and giggles I started looking in = the >>>>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >>>>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >>>>> have been reading up on the atmel board support package so I >>>>> recognized the at91 moniker. (pretty pleased with myself for that >>>>> one...) >>>>>=20 >>>>> So what I can tell is someone needs to write a mx53/mx6 nand flash >>>>> controller that works in roughly the same way as the at91 = "prototype". >>>>> It would implement various functions and then assign them using: >>>>>=20 >>>>> static device_method_t at91_nand_methods[] =3D { >>>>> DEVMETHOD(device_probe, at91_nand_probe), >>>>> DEVMETHOD(device_attach, at91_nand_attach), >>>>>=20 >>>>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>>>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>>>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>>>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>>>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>>>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>>>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>>>=20 >>>>> DEVMETHOD_END >>>>> }; >>>>>=20 >>>>>=20 >>>>> Or some rough order of magnitude in that direction? That would be >>>>> where some of the "pre-canded jobs" mentioned in the spec would = come >>>>> in handy? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Russ >>>>>=20 >>>>=20 >>>> If the flash parts in use on your board can use 1-bit Hamming code = for >>>> ECC, all you need to do is write a nearly-trivial nfc driver = similar to >>>> at91_nfc. If the flash chips are modern and require multi-bit BCH = code, >>>> we don't have a software implementation of that, and the current = NFC >>>> interface has no provisions for using the hardware accellerator on = the >>>> imx chip. >>>>=20 >>>> I can't find any definitive info on what chips that board uses, but = I >>>> will mention that 1-bit ECC was used on old chips with small = capacities >>>> long ago and probably isn't used on any modern boards. >>>>=20 >>>> -- Ian >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley = wrote: >>>>>> Warner, >>>>>> That's great news! I had a scan and it seemed pretty thorough = (albiet >>>>>> from a novice point of view). The pre-canned jobs looked = promising. >>>>>>=20 >>>>>> As much as I'm hoping your intention is to fix this FOR me, could = you >>>>>> point me towards the code for the mtd support? >>>>>>=20 >>>>>> Many thanks to everyone for helping. I've had more progress in = the >>>>>> last two weeks than I have in the previous six months. lolz >>>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh = wrote: >>>>>>> Hey Russ, >>>>>>>=20 >>>>>>> A quick read suggests all, or nearly all, of the data needed to = write a full NFC for this chip is present. The programming and read = sequences and information about ECC error rates appear to be readily = available. The exact ECC used, however, appears opaque. This may or may = not be a problem. It even appears to have command sequencing built into = the controller. This is a great feature, but one the current code = doesn=92t make use of. >>>>>>>=20 >>>>>>> Warner >>>>>>>=20 >>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley = wrote: >>>>>>>=20 >>>>>>>> Warner, >>>>>>>>=20 >>>>>>>> I was looking for a Digi reference but it turns out the Nand = Flash Controller is part of the Freescale Processor. Here is the link to = the Reference Manual: >>>>>>>>=20 >>>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>>>=20 >>>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page = 3647. >>>>>>>>=20 >>>>>>>> Is this relevant to what you are looking at doing? = https://wiki.freebsd.org/NAND >>>>>>>>=20 >>>>>>>> I also found something called CHFS for NetBSD that looks = interesting: http://chewiefs.sed.hu/home >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Russ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh = wrote: >>>>>>>>=20 >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>>>=20 >>>>>>>>> Warner, >>>>>>>>>=20 >>>>>>>>> First, I was just watching your 2010 talk on supporting = FreeBSD in a commercial environment. Has there been any updates in the = process of maintaining a commercial branch in the last 4 years (not that = I have any commercial ventures yet! lolz)? >>>>>>>>>=20 >>>>>>>>> Anyway, I talked to an Engineer about the NAND controller spec = and he chided me for being naive (poor little software developer, in way = over his head. tisk tisk). He mentioned a FIVE THOUSAND page reference = manual, which I have yet to find on the Digi site. >>>>>>>>=20 >>>>>>>> URL + section number. 5k pages doesn=92t necessarily mean it = will be useful, though. :( >>>>>>>>=20 >>>>>>>>> I have however found this hardware reference: >>>>>>>>>=20 >>>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>>>=20 >>>>>>>>> =46rom Page 41: >>>>>>>>>=20 >>>>>>>>> NAND flash memory >>>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash = memory. On the module in >>>>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip = is used. This NAND flash >>>>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>>>> The NAND flash controller signals are available on the module = connectors. >>>>>>>>=20 >>>>>>>> This basically says nothing more useful than =93There=92s NAND = on this board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. >>>>>>>>=20 >>>>>>>>> There are pin references to NAND further down in the section = "GPIO multiplexing table in the ConnectCore for i.MX53 module" on page = 44 and 49. >>>>>>>>>=20 >>>>>>>>> I fear this is not the information we are looking for. >>>>>>>>=20 >>>>>>>> Not really. The GPIO info might be mildly helpful in a few = cases >>>>>>>>=20 >>>>>>>>> I have found another u-boot fork for the CCWMX53 on github = here: https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>>>=20 >>>>>>>>> With what seems to be the information about booting from NAND = here: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>>>=20 >>>>>>>>> If you can let me know what I am looking for I can both ask a = more directed question at work and also perform a better search. >>>>>>>>>=20 >>>>>>>>> I have also started looking over the Architecture handbook as = well because I have a feeling there is going to be lots of driver code = in my future. >>>>>>>>=20 >>>>>>>> A good first step would be to get a URL or search string to get = the URL for that big spec. It is of the right size to possibly be = useful, but sometimes really long specs have 1-2 page descriptions of = things like the SD controller or the NAND controller that you need = special NDAs + business arrangements to get, so it is hard to say=85 >>>>>>>>=20 >>>>>>>> Warner >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh = wrote: >>>>>>>>>=20 >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>>>=20 >>>>>>>>>> I will attempt to load the kernel from tftp as soon as I can. = I will need >>>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>>>=20 >>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was = hoping to >>>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>>>=20 >>>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>>> #go 0x70800000; >>>>>>>>>>=20 >>>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>>>=20 >>>>>>>>>> On another note, do you know where I could find out more = about the missing >>>>>>>>>> MTD support? >>>>>>>>>=20 >>>>>>>>> A spec for the NAND controller is needed to make that work=85 = Is one about? >>>>>>>>>=20 >>>>>>>>> Warner >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, = so many cool >>>>>>>>>> projects, so little time... >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> Russ >>>>>>>>>>=20 >>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo = wrote: >>>>>>>>>>=20 >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Rui, >>>>>>>>>>>>=20 >>>>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot = the kernel >>>>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>>>> =95 >>>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go >>>>>>>>>>> 0x40f00000" >>>>>>>>>>>>=20 >>>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>>>=20 >>>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>>>=20 >>>>>>>>>>> You can't use the Arndale config since the load addresses = are different. >>>>>>>>>>> You should be able to load a kernel from the network. Can = you do that? >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Rui Paulo >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>=20 >>>>=20 >>>>=20 >>=20 --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNCENAAoJEGwc0Sh9sBEA2kMP+wRql87x2zpw+rgq3pmJZSli BclQQs2UpM1K/4NWotggDC70Hl1ZBe4DNfJWxYAuYUj7qH72qqLz7Obql1d/N741 V7zCQUFUjDQYHUAYqJHOkQYbWJG9GH2zI+ImLVqVfQZGPY1zuTjCOZ1ZLDt5vKUJ TU/15b01wwk0pib6xTuYcYHDptd6bxWj9AmiDtkX3EununxraFwSiB0E4uCEdWtW sS42PGi2LHVR5X4AXCwuEsnIHHSg3k6qEn2vXCvznRAs4GGfCFkOI7n2XHlTHSQr LariOExZLnefusS6KDKpG9xjNTENp3Q+f6TojFcVGOjCLmm0Jh1W55dPAazSBHCK twsgVgtHflYJ12dGx3wfa1lFz9OJj7z4aumWn4DzRaQcvI5KI5KoeKVbCYoFQ6d1 kt61dAmTtUpGPAL/tRXk/eVC6gHPR9OTWkd04eGkTN2YJIgtNvXLzSenF9WJYoxc ABCt+l4d62QOhy7Q7i7oHaP6qa3Vo9rWuKAPSyFCNLLDakFLGr5J19IrDolW6a0P TpCPNyxCPTA/NyvwGF6w2yLr9+YxxzJzuijOaMrsg8UoR7Ss2SljSXPhxGZFFor/ Gg5pzgSu+Mjr0r9McR6Wj3VTksDZcMxcICrfwTgAa+bpuv6WhL2nzmuDZeEbxfpi G1uGn9f1JNu8nnOR7bjj =LKtN -----END PGP SIGNATURE----- --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726--