From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 04:41:42 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 A699B2F1; Tue, 7 Oct 2014 04:41:42 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 510E2E99; Tue, 7 Oct 2014 04:41:42 +0000 (UTC) Received: by mail-yk0-f181.google.com with SMTP id q200so2556830ykb.12 for ; Mon, 06 Oct 2014 21:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DepDNcraGv7q+1Zzgyfhe1sLwFWcpEiNyv6pttSyZyo=; b=sTyoBjfOh4Ev5IcpvCEe3K2k4pLbBKQIh4nHhAoKtTGhi6iP9qD9a4RIg1OmKy+x/W IabDpPZfC491kTCy44+WHE0MPj/3S54U67xc3v0CNzN4snIydn45Kmzg3Uvr/mFshuNM Bh7dosk/X9lJiI4dAuLEu1mlCg9XKhyc9lDDk3RZAjgZt0K72luS3bxHFNEkGGK8ZtAH DxnNM5gVJJwm8mot/ZSIdVw3HYc8WUPmfdlnpwWoG1/OqBoGgZim+h7si7GeOZfnCapq LPS7y4E+5KHwTqV2SrQJy0lBDvYsV80jstVxBnrqDM/ApDrAnUzd0dnI2lKUfkkOyZwL DNWw== MIME-Version: 1.0 X-Received: by 10.236.39.177 with SMTP id d37mr1920540yhb.121.1412656901403; Mon, 06 Oct 2014 21:41:41 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Mon, 6 Oct 2014 21:41:41 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 21:41:41 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh , Ian Lepore , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 04:41:42 -0000 Hey, Okay, I lied about waiting till the weekend. I am looking at the atmel files. Should I be replacing the at91 moniker with imx (processor class) or mx53 (implementation)? Thanks, Russ On Mon, Oct 6, 2014 at 3: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. > > 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 > > On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: >> >> On Oct 6, 2014, at 1:35 PM, Russell Haley wrote: >> >>> 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)? >>> >>> 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? >>> >>> Also, I was wondering how closely the CWMX53 board support has >>> followed the guidelines here: >>> https://wiki.freebsd.org/FreeBSDArmBoards? >> >> I don=E2=80=99t 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. >> >> 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 en= ough. >> >> Ideally, we can accept a divergence of ECC in the details, and instead a= llow >> for full and partial hardware offload for ECC generation and correction. >> >> Warner >> >> >>> 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 a= s >>>>> 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...) >>>>> >>>>> 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: >>>>> >>>>> static device_method_t at91_nand_methods[] =3D { >>>>> DEVMETHOD(device_probe, at91_nand_probe), >>>>> DEVMETHOD(device_attach, at91_nand_attach), >>>>> >>>>> 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), >>>>> >>>>> DEVMETHOD_END >>>>> }; >>>>> >>>>> >>>>> 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? >>>>> >>>>> Thanks, >>>>> >>>>> Russ >>>>> >>>> >>>> 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 t= o >>>> at91_nfc. If the flash chips are modern and require multi-bit BCH cod= e, >>>> 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. >>>> >>>> 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 capacitie= s >>>> long ago and probably isn't used on any modern boards. >>>> >>>> -- Ian >>>> >>>> >>>>> >>>>> >>>>> 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 (albie= t >>>>>> from a novice point of view). The pre-canned jobs looked promising. >>>>>> >>>>>> As much as I'm hoping your intention is to fix this FOR me, could yo= u >>>>>> point me towards the code for the mtd support? >>>>>> >>>>>> 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 >>>>>> >>>>>> Russ >>>>>> >>>>>> >>>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: >>>>>>> Hey Russ, >>>>>>> >>>>>>> A quick read suggests all, or nearly all, of the data needed to wri= te 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 e= xact ECC used, however, appears opaque. This may or may not be a problem. I= t even appears to have command sequencing built into the controller. This i= s a great feature, but one the current code doesn=E2=80=99t make use of. >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley w= rote: >>>>>>> >>>>>>>> Warner, >>>>>>>> >>>>>>>> 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 Ref= erence Manual: >>>>>>>> >>>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>>> >>>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >>>>>>>> >>>>>>>> Is this relevant to what you are looking at doing? https://wiki.fr= eebsd.org/NAND >>>>>>>> >>>>>>>> I also found something called CHFS for NetBSD that looks interesti= ng: http://chewiefs.sed.hu/home >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Russ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote= : >>>>>>>> >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>>> >>>>>>>>> Warner, >>>>>>>>> >>>>>>>>> First, I was just watching your 2010 talk on supporting FreeBSD i= n a commercial environment. Has there been any updates in the process of ma= intaining a commercial branch in the last 4 years (not that I have any comm= ercial ventures yet! lolz)? >>>>>>>>> >>>>>>>>> Anyway, I talked to an Engineer about the NAND controller spec an= d 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. >>>>>>>> >>>>>>>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it= will be useful, though. :( >>>>>>>> >>>>>>>>> I have however found this hardware reference: >>>>>>>>> >>>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>>> >>>>>>>>> From Page 41: >>>>>>>>> >>>>>>>>> NAND flash memory >>>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash memo= ry. 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 con= nectors. >>>>>>>> >>>>>>>> This basically says nothing more useful than =E2=80=9CThere=E2=80= =99s NAND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is use= ful, 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=E2=80=99t answer that so= rt of question from the docs you have, then they aren=E2=80=99t helpful eno= ugh. >>>>>>>> >>>>>>>>> There are pin references to NAND further down in the section "GPI= O multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 4= 9. >>>>>>>>> >>>>>>>>> I fear this is not the information we are looking for. >>>>>>>> >>>>>>>> Not really. The GPIO info might be mildly helpful in a few cases >>>>>>>> >>>>>>>>> I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>>> >>>>>>>>> With what seems to be the information about booting from NAND her= e: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>>> >>>>>>>>> If you can let me know what I am looking for I can both ask a mor= e directed question at work and also perform a better search. >>>>>>>>> >>>>>>>>> I have also started looking over the Architecture handbook as wel= l because I have a feeling there is going to be lots of driver code in my f= uture. >>>>>>>> >>>>>>>> A good first step would be to get a URL or search string to get th= e 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=E2=80=A6 >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wr= ote: >>>>>>>>> >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was ho= ping to >>>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>>> >>>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>>> #go 0x70800000; >>>>>>>>>> >>>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>>> >>>>>>>>>> On another note, do you know where I could find out more about t= he missing >>>>>>>>>> MTD support? >>>>>>>>> >>>>>>>>> A spec for the NAND controller is needed to make that work=E2=80= =A6 Is one about? >>>>>>>>> >>>>>>>>> Warner >>>>>>>>> >>>>>>>>> >>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so = many cool >>>>>>>>>> projects, so little time... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Russ >>>>>>>>>> >>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote= : >>>>>>>>>> >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>>> >>>>>>>>>>>> Rui, >>>>>>>>>>>> >>>>>>>>>>>> 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: >>>>>>>>>>>> =E2=80=A2 >>>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kerne= l.bin; go >>>>>>>>>>> 0x40f00000" >>>>>>>>>>>> >>>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>>> >>>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>>> >>>>>>>>>>> You can't use the Arndale config since the load addresses are d= ifferent. >>>>>>>>>>> You should be able to load a kernel from the network. Can you = do that? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Rui Paulo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebs= d.org" >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> 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= " >>>>> >>>> >>>> >>