From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 19:35:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 925A5E08; Mon, 6 Oct 2014 19:35:03 +0000 (UTC) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (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 3F1FFD83; Mon, 6 Oct 2014 19:35:03 +0000 (UTC) Received: by mail-yh0-f51.google.com with SMTP id 29so2329952yhl.38 for ; Mon, 06 Oct 2014 12:35:02 -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 :cc:content-type:content-transfer-encoding; bh=LFF8U1fNZrN9srVhQLNWgRqn/R4Ge2lg1rK/uR3+zy4=; b=M3Npp5iX9bw1wkNMYmO9EhpJ0pEMIGNoS6BAwUqFIgtPAKF/YP+7Q3HII/a305xfnm bK25pQfXxdZovKEwAziloosT25Eo/JDEhSHh+vHBlPI2ldD6gD3987mjx73rk+2kjT8z hENkxwvT9ljcu22w3LOBobVnhMyd+hYpHhOdhWKt12ammtT3GC21nYrXi+HD0oJCalLg duZwhfggFHaDkoOr+wwIYOQME79DFVDBZ3/34ahBIFc/78QxDHoKC7UI06p3a9zRo0ND 0p1aieqSpsfGVZ2GJx9Eb1BdrArH4r1tlSCGBiEG9rhQn9LbK4QHVyTUvHSaMnzMwRbd hV+w== MIME-Version: 1.0 X-Received: by 10.236.70.229 with SMTP id p65mr39712005yhd.50.1412624102319; Mon, 06 Oct 2014 12:35:02 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Mon, 6 Oct 2014 12:35:02 -0700 (PDT) In-Reply-To: <1412613830.12052.121.camel@revolution.hippie.lan> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 12:35:02 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, 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: Mon, 06 Oct 2014 19:35:03 -0000 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? 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...) >> >> 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 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. > > 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. > > -- Ian > > >> >> >> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley wro= te: >> > 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. >> > >> > 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? >> > >> > 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 write= a full NFC for this chip is present. The programming and read sequences an= d information about ECC error rates appear to be readily available. The exa= ct 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=E2=80=99t make use of. >> >> >> >> Warner >> >> >> >> On Oct 2, 2014, at 10:44 PM, Russell Haley wro= te: >> >> >> >>> Warner, >> >>> >> >>> I was looking for a Digi reference but it turns out the Nand Flash C= ontroller is part of the Freescale Processor. Here is the link to the Refer= ence 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.free= bsd.org/NAND >> >>> >> >>> I also found something called CHFS for NetBSD that looks interesting= : 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 wr= ote: >> >>> >> >>> > Warner, >> >>> > >> >>> > First, I was just watching your 2010 talk on supporting FreeBSD in= a commercial environment. Has there been any updates in the process of mai= ntaining a commercial branch in the last 4 years (not that I have any comme= rcial ventures yet! lolz)? >> >>> > >> >>> > 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, w= hich I have yet to find on the Digi site. >> >>> >> >>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it w= ill 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 memor= y. On the module in >> >>> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is u= sed. This NAND flash >> >>> > device is connected to NAND flash Chip Select 0. >> >>> > The NAND flash controller signals are available on the module conn= ectors. >> >>> >> >>> This basically says nothing more useful than =E2=80=9CThere=E2=80=99= s NAND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D 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=E2=80=99t answer that sort = of question from the docs you have, then they aren=E2=80=99t helpful enough= . >> >>> >> >>> > 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= . >> >>> > >> >>> > 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: h= ttps://github.com/Varcain/uboot-ccwmx53-digi >> >>> > >> >>> > With what seems to be the information about booting from NAND here= : 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 more= directed question at work and also perform a better search. >> >>> > >> >>> > 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 fu= ture. >> >>> >> >>> 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 s= ometimes really long specs have 1-2 page descriptions of things like the SD= controller or the NAND controller that you need special NDAs + business ar= rangements to get, so it is hard to say=E2=80=A6 >> >>> >> >>> Warner >> >>> >> >>> > >> >>> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wro= te: >> >>> > >> >>> > 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" >> > >