From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:30:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52014BE5 for ; Tue, 7 Oct 2014 17:30:50 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11E591F5 for ; Tue, 7 Oct 2014 17:30:49 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id eu11so7538218pac.21 for ; Tue, 07 Oct 2014 10:30:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SmmOhPijMR4Q6sSnlO09VBn2OIat4S+PY0raCbLwm8I=; b=QlqZHTliIUAvv2iGNlSQhb3uCy3+a+EvJW+pJAbw0miNF2Y+1rso15DCIQwlMuAP7A tDWVXgaXAuw7Eh0jEFtsJGcFKSEiSA3p9HoQQ5snVX+DNDC1cfajyHkIxY/6sAGuWSef iB2vfisaHQly1cEfrpZhhLixBo/57mepBARb1YV9wJkbyQXtvPcUHJbRmHu4dwP0gbY5 rcbmDkjY0Eb7aAAh9/MctuMpx2pkQJZ56M0TYx+ZzRg4nJSpyA4AxLuv56RKrBAyIABR mCv7iIvE1bVUCLHe/afUk5BzrLULVBl4DEiNUSFDWFtKc6Igq9q8fMxzBD/9sW9tUn7O 00yw== X-Gm-Message-State: ALoCoQl5PCi+9Q2l+K60s1s5FeycV9eVZXFNh1oplEG11X4/sR4RoCIfIP1XkW6f+ctP4iVCkRTS X-Received: by 10.70.55.232 with SMTP id v8mr5337059pdp.93.1412702701279; Tue, 07 Oct 2014 10:25:01 -0700 (PDT) Received: from [10.64.26.130] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fn4sm16802129pab.39.2014.10.07.10.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 10:25:00 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Tue, 7 Oct 2014 11:24:57 -0600 Message-Id: <0D4A5ED2-B033-40ED-AA64-312E95B02F11@bsdimp.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:30:50 -0000 --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 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 = 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 wrote: >>>=20 >>> On Oct 6, 2014, at 1:35 PM, Russell Haley = 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 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 = 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 = 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 = 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 = wrote: >>>>>>>>>=20 >>>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = 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 = wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = 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 = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = 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--