Date: Tue, 7 Oct 2014 11:21:16 -0600 From: Warner Losh <imp@bsdimp.com> To: Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org>, Rui Paulo <rpaulo@me.com> Subject: Re: Digi CCWMX53 Message-ID: <2C5A1F77-C3DD-4146-9A08-93625B7B8291@bsdimp.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
--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 <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. 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 <imp@bsdimp.com> wrote: >>=20 >> On Oct 6, 2014, at 1:35 PM, Russell Haley <russ.haley@gmail.com> = 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 <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...) >>>>>=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 = <russ.haley@gmail.com> 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 <imp@bsdimp.com> = 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 = <russ.haley@gmail.com> 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 <imp@bsdimp.com> = wrote: >>>>>>>>=20 >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = <russ.haley@gmail.com> 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 <imp@bsdimp.com> = wrote: >>>>>>>>>=20 >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = <russ.haley@gmail.com> 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 <rpaulo@me.com> = wrote: >>>>>>>>>>=20 >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = <russ.haley@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2C5A1F77-C3DD-4146-9A08-93625B7B8291>