Date: Mon, 6 Oct 2014 15:11:12 -0700 From: Russell Haley <russ.haley@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org>, Rui Paulo <rpaulo@me.com> Subject: Re: Digi CCWMX53 Message-ID: <CABx9NuQQ3VQCLk0xGXxk-R_eUVdeMOKZWDg%2BS1yXf30fCP7Sow@mail.gmail.com> In-Reply-To: <FCE5AA26-AD01-4A61-8E1B-3CBCBBA07CB0@bsdimp.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 m= ost 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 eno= ugh. > > Ideally, we can accept a divergence of ECC in the details, and instead al= low > 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 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 <russ.haley@gmail.com> w= rote: >>>>> 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 <imp@bsdimp.com> wrote: >>>>>> Hey Russ, >>>>>> >>>>>> A quick read suggests all, or nearly all, of the data needed to writ= e a full NFC for this chip is present. The programming and read sequences a= nd information about ECC error rates appear to be readily available. The ex= act 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 <russ.haley@gmail.com> wr= ote: >>>>>> >>>>>>> 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 Refe= rence 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.fre= ebsd.org/NAND >>>>>>> >>>>>>> I also found something called CHFS for NetBSD that looks interestin= g: 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> w= rote: >>>>>>> >>>>>>>> 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 = 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 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= =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 "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 = sometimes really long specs have 1-2 page descriptions of things like the S= D controller or the NAND controller that you need special NDAs + business a= rrangements 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> wro= te: >>>>>>>> >>>>>>>> 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 w= ill need >>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>> >>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was hop= ing 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 th= e 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 m= any 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 kernel= .bin; go >>>>>>>>>> 0x40f00000" >>>>>>>>>>> >>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>> >>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>> >>>>>>>>>> You can't use the Arndale config since the load addresses are di= fferent. >>>>>>>>>> You should be able to load a kernel from the network. Can you d= o 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@freebsd= .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?CABx9NuQQ3VQCLk0xGXxk-R_eUVdeMOKZWDg%2BS1yXf30fCP7Sow>