Digi CCWMX53

Russell Haley russ.haley at gmail.com
Tue Oct 7 04:41:42 UTC 2014 

Hey,

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)?

Thanks,

Russ

On Mon, Oct 6, 2014 at 3:11 PM, Russell Haley <russ.haley at 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.
>
> 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 at bsdimp.com> wrote:
>>
>> On Oct 6, 2014, at 1:35 PM, Russell Haley <russ.haley at 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’t 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 at 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[] = {
>>>>> 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 at 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.
>>>>>>
>>>>>> 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 at bsdimp.com> wrote:
>>>>>>> Hey Russ,
>>>>>>>
>>>>>>> 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’t make use of.
>>>>>>>
>>>>>>> Warner
>>>>>>>
>>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley <russ.haley at gmail.com> wrote:
>>>>>>>
>>>>>>>> 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 Reference 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.freebsd.org/NAND
>>>>>>>>
>>>>>>>> I also found something called CHFS for NetBSD that looks interesting: http://chewiefs.sed.hu/home
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Russ
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>>>>>>
>>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley <russ.haley at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> 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 maintaining a commercial branch in the last 4 years (not that I have any commercial 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, which I have yet to find on the Digi site.
>>>>>>>>
>>>>>>>> URL + section number. 5k pages doesn’t 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 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.
>>>>>>>>
>>>>>>>> This basically says nothing more useful than “There’s NAND on this board that’s 4Gbits on CS0.” 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’t answer that sort of question from the docs you have, then they aren’t helpful enough.
>>>>>>>>
>>>>>>>>> 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: https://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 future.
>>>>>>>>
>>>>>>>> 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…
>>>>>>>>
>>>>>>>> Warner
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh <imp at bsdimp.com> wrote:
>>>>>>>>>
>>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley <russ.haley at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was hoping 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 the missing
>>>>>>>>>> MTD support?
>>>>>>>>>
>>>>>>>>> A spec for the NAND controller is needed to make that work…  Is one about?
>>>>>>>>>
>>>>>>>>> Warner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool
>>>>>>>>>> projects, so little time...
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Russ
>>>>>>>>>>
>>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at 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:
>>>>>>>>>>>>     •
>>>>>>>>>>>> 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 different.
>>>>>>>>>>> You should be able to load a kernel from the network.  Can you do that?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Rui Paulo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> freebsd-arm at freebsd.org mailing list
>>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> freebsd-arm at freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>>>>
>>>>
>>>>
>>

More information about the freebsd-arm mailing list