Date: Mon, 6 Oct 2014 21:41:41 -0700 From: Russell Haley <russ.haley@gmail.com> To: Warner Losh <imp@bsdimp.com>, Ian Lepore <ian@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: Digi CCWMX53 Message-ID: <CABx9NuQ-FpM5WUp9M4TaqaqgX-9H-zX6S4YGmAiJfWOmCmp_7g@mail.gmail.com> In-Reply-To: <CABx9NuQQ3VQCLk0xGXxk-R_eUVdeMOKZWDg%2BS1yXf30fCP7Sow@mail.gmail.com> References: <CABx9NuQr%2BdEb_yj3ypEe6Sb_qPY%2BqP74n0x1K5=_K6Zoio2vkw@mail.gmail.com> <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com> <CABx9NuTU=E7ceQ=5=Qk%2B=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com> <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com> <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi%2BA@mail.gmail.com> <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com> <CABx9NuROVKvAcqj166=z%2BvP5zemjost6m12H5fLvEbKU8%2BA0xw@mail.gmail.com> <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <CABx9NuRybC-8z4XTMO=0vu824%2BEzVhiDu-vsxteBr6zchorgmA@mail.gmail.com> <DD01C5E3-15BE-4953-A4AA-C0F67D2F0382@bsdimp.com> <CABx9NuRwenFSPkg-8o5ba=-_82WakXuOyCiiS=Rbxegwcp1GfQ@mail.gmail.com> <CABx9NuScNhPPMsHL_x8xuYR0Oz97CM9wmRxuXxFSRMT10RKXJQ@mail.gmail.com> <1412613830.12052.121.camel@revolution.hippie.lan> <CABx9NuRFBvP4SG9%2BnvV=MwYpbRMfy%2BjJOv=wmx7xNO9tiK-8qg@mail.gmail.com> <FCE5AA26-AD01-4A61-8E1B-3CBCBBA07CB0@bsdimp.com> <CABx9NuQQ3VQCLk0xGXxk-R_eUVdeMOKZWDg%2BS1yXf30fCP7Sow@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <russ.haley@gmail.com> 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 <imp@bsdimp.com> wrote: >> >> On Oct 6, 2014, at 1:35 PM, Russell Haley <russ.haley@gmail.com> 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 <ian@freebsd.org> 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 <russ.haley@gmail.com> = 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 <imp@bsdimp.com> 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 <russ.haley@gmail.com> 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 <imp@bsdimp.com> wrote= : >>>>>>>> >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley <russ.haley@gmail.com> = 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 <imp@bsdimp.com> wr= ote: >>>>>>>>> >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley <russ.haley@gmail.com>= 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 <rpaulo@me.com> wrote= : >>>>>>>>>> >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley@gmail.com>= 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= " >>>>> >>>> >>>> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuQ-FpM5WUp9M4TaqaqgX-9H-zX6S4YGmAiJfWOmCmp_7g>