Date: Tue, 7 Oct 2014 11:24:57 -0600 From: Warner Losh <imp@bsdimp.com> To: Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm@freebsd.org, Ian Lepore <ian@freebsd.org> Subject: Re: Digi CCWMX53 Message-ID: <0D4A5ED2-B033-40ED-AA64-312E95B02F11@bsdimp.com> In-Reply-To: <CABx9NuQ-FpM5WUp9M4TaqaqgX-9H-zX6S4YGmAiJfWOmCmp_7g@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> <CABx9NuQ-FpM5WUp9M4TaqaqgX-9H-zX6S4YGmAiJfWOmCmp_7g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 6, 2014, at 10:41 PM, Russell Haley <russ.haley@gmail.com> wrote: > Hey, >=20 > 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)? Well, there=92s a third possibility. Is this used across all freescale = products? if so, then you=92d want to use that moniker. Arguably the Atmel one = should be named atmel, not at91. Changing everything though is just churn for = no benefit. Use the most general moniker you can and still be accurate. If = the imx6 is the same as the imx53, then go with imx. If it is the same chip = they use in the MIPS SoCs or the PowerPC SoCs, then go with the most common freecsale abbreviation. Warner > Thanks, >=20 > Russ >=20 > 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. >>=20 >> 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 >>=20 >> 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=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98 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 iQIcBAEBCgAGBQJUNCHpAAoJEGwc0Sh9sBEAyhwP/AjFLAi0DvVrhwtRN58scAJO jl790cClEmtwSn3ojzvxf3dChLEZuBY9SGhyVDpGA+HZnCrEXkzkc1/VSFgQglvM xJlApcx1B9hju640i9SdHATZ1/YmUDPRRdYIUGXxYWj3DJazf9ZrTCOBKKDm/Ph7 BMhHShr3caM5OwXSVvnSaCDSsgQ5Ha1a+ecAfu6iqUJWhLnDM/BbOqrgAq9novNG hlNkroA/WHHXqLuUHnn82abIrrhFT61RIPOWjSucaJmbCORIIu7CBKHoq2U3Y37+ xeZ0VeWs/ErsYmwi2eIZBe139vU5j0Lz26HSG6im6C09Oa7n9nJi1FNP6Qsv+97i ZlMqqD6n85i6HgAdUNLqXZb32JImYQLpJPX+Dvcw27NbaA8W+fMhYjBNYJBNfqwR lys1CcxKh/SCsMs99QLMenq7Xew/N+iax+g07tL0kb2xA63h3bterP8QUggdjuMA 7NGA/g6EfWHs+HrtCyzyvmCSuuRpfgAQi/V67NoYn+KpItyRQZHEWqtWiI7c4/9X skE767dHNnL+0WVb4MuBnl0Ul3THv6Q/EHJgpqQ1jtpuQin2YyiWT3HOAQOEnibM UIiWcUhLVyMGLfRJUMnyx+SJmiQeMPfCUxuwh0gw2chmeMt7V81PJmh6laVJiZgT IM6wfExClI/dxNcuB6DI =TOQl -----END PGP SIGNATURE----- --Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D4A5ED2-B033-40ED-AA64-312E95B02F11>