Date: Mon, 6 Oct 2014 15:30:35 -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: <FCE5AA26-AD01-4A61-8E1B-3CBCBBA07CB0@bsdimp.com> In-Reply-To: <CABx9NuRFBvP4SG9%2BnvV=MwYpbRMfy%2BjJOv=wmx7xNO9tiK-8qg@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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)? >=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? 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. 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. 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. 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...) >>>=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 --Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602 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 iQIcBAEBCgAGBQJUMwn7AAoJEGwc0Sh9sBEA7aQP/0FokXHQ5sbYagwZuyr4gV8y qyE501kgYAwfBC6KxJN7ORKoAMkJ5B3nyMuHEnSUVo0kfzyeIxVMC6VEok1hCryt XweZIwjduwR1Nmrl7R0mbaUNNKPfYRFQfYbcGLITShGAq5i4YX4cBLbkE4oorYpC 5dvRO7QJ8JdIYnh3oaQkQvkLdxLlJjdDdOvSlT8HYC2obvpdDkTUnOz5tQFZzLmj WWlO8QhNJynMeM25SkHDqXvUXE2iqG1F5PNVzZcHh8ebr9EGM+ophSv0R4IfXFKo slgEEE32F1oYnzeJVc6dRdZ8ziyiIh3+mqq8WqV0KRV9E38ctkeagrQ0onZhDCkQ 0NpQWiErCJRXOno49nqQJCU3ZdMXRfpM0o1AVbsf2Ah7vE1Nt08/c6XM90ddTI84 BzwaYbTQZ6z7XbppnGBddnVSfP+WBREP2Dnt6XTY635DCbM3VoQQ0ZfwtIs6xH5W tj4kLYIZxHAJl6vvXPgzPhxEKB7ChRIb5I1N9pnJ5a5TR8dKEdKKDmI+ha40tP3q ELtgKNfHngeGjnl5GhdlwFgSVp1yUodLZclSC1H0sm7QH31uZDjfxJfT/ItOTaVg nGS4mHjTc2L4Oj8ijPvbBaqIhT9Bap9ga0D2puYSuPlSM2E+YtNvLdfmkcUztNQ0 ZTEYmraPrcKnROxo4CRS =Woui -----END PGP SIGNATURE----- --Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FCE5AA26-AD01-4A61-8E1B-3CBCBBA07CB0>