SAMA5D2_PTC_EK--does nand work?

Moderator: nferre

bmpenrod
Posts: 17
Joined: Wed Feb 07, 2018 9:39 pm

SAMA5D2_PTC_EK--does nand work?

Thu Apr 19, 2018 10:23 pm

Developing a custom board based on SAMA5D27 SIP and Micron MT29F4G08ABADAWP chip, which is the chip used on the SAMA5D2_PTC_EK board. Wondering if anyone is getting that nand to work with the linux-at91 kernel?

I'm seeing driver incompatibilities in the 4.9.75 circa late January 2018 kernel.
rwalden
Posts: 1
Joined: Sat May 19, 2018 11:45 pm

Re: SAMA5D2_PTC_EK--does nand work?

Sat May 19, 2018 11:50 pm

Did you get this working? I am also designing a board based on the SAMA5D27SiP with NAND. Any advice about what you would change in your hardware design?
bmpenrod
Posts: 17
Joined: Wed Feb 07, 2018 9:39 pm

Re: SAMA5D2_PTC_EK--does nand work?

Tue Jul 24, 2018 1:09 am

Sorry for the very late response.

No, I ended up abandoning it as no one has ever responded to say that it works!!! The problems I was seeing could only be incompatibilities between the linux nand driver and the sama5d27 internal flash controller. It's possible that since I am not using u-boot, there was some missing setup magic that was not occurring when I was using at91bootstrap.

I ended up using the microSD interface, which appears to be rock solid. The industrial quality cards are now implementing the same high reliability algorithms present in the linux mtd, and the nilfs file system is a good replacement for ubifs in that it does not need a file system checker after a power cut, and it implements a further element of wear leveling above the card internal algorithms.

So far I'm pretty happy with getting out of the nand flash trap. It's never easy, even when you do get it to work.
blue_z
Location: USA
Posts: 1703
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D2_PTC_EK--does nand work?

Tue Jul 24, 2018 2:25 am

bmpenrod wrote:The problems I was seeing could only be incompatibilities between the linux nand driver and the sama5d27 internal flash controller.
Of course someone else's software has to be at fault even though your hardware configuration doesn't adhere to a mandatory IO set requirement stipulated in the SoC datasheet.

As I recall you (first claimed that you could leave an input unconnected, but then) decided to utilize a pin from IOSET1 while using IOSET2 NAND connections (despite my suggestion of using an alternate IOSET2 pin).
Recently I read the following in the SAMA5D2 datasheet:

I/Os for each peripheral are grouped into IO sets,...
For all peripherals, it is mandatory to use I/Os that belong to the same IO set.
The timings are not guaranteed when IOs from different IO sets are mixed.


Regards

Return to “SAMA5-based”

Who is online

Users browsing this forum: No registered users and 2 guests