On Tuesday, December 09, 2014 at 08:20:51 AM, Stefan Roese wrote:
On 08.12.2014 23:53, Scott Wood wrote:
>> => nand device >> >> Device 0: 2x nand0, sector size 128 KiB >> >> Page size 2048 b >> OOB size 64 b >> Erase size 131072 b > > Shouldn't you see "Device 0" and "Device 1" ?
The "2x" indicates that there are two identical chips being treated as a single device (chip->numchips).
Is that correct ? What if I have two different NAND chips on this controller?
Then they need to be represented as separate NAND devices, rather than multiple chips on one device.
Gee, I wouldn't have though of that, really ;-)
Well, you asked a vague question...
So is this patch correct or not ?
In all its details? I don't know, as I'm not familiar with the hardware. With regards to the question about non-identical devices, this patch doesn't add support for that. So it's a question of what the requirements are, and whether it's being used in the right circumstances. If you have non-identical NAND chips, make sure CONFIG_SYS_NAND_MAX_CHIPS is 1.
Correct. Using CONFIG_SYS_NAND_MAX_CHIPS support identical chips. This is exactly what I need in my case. And is also needed for NAND devices that have multiple NAND chips embedded on one die. You then need this possibility to support multiple chips. Otherwise not the whole device can be accessed.
A better question might be, does this approach make sense, versus implementing support for multiple devices? What does Linux support?
Linux does it exactly in the same way:
[ 1.089439] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc [ 1.095864] nand: Micron MT29F4G08ABADAH4 [ 1.099896] nand: 512MiB, SLC, page size: 2048, OOB size: 64 [ 1.105871] nand: 2 chips detected ...
And exposes those 2 chips as one NAND device. By using this patch we also use the same MTD partitioning in U-Boot and Linux (mtdparts environment).
I hope now all is clear.
Yes, it is now. Thank you both for the detailed explanation!
Acked-by: Marek Vasut marex@denx.de
Best regards, Marek Vasut