i.MX28 gpmi-nand underlying geometry

I'm trying to get the Freescale kobs-ng tool (used to burn boot images to NAND) working under a current kernel.

Under the 2.6 kernel that Freescale ships with their BSP, access to the NAND is via the gpmi-nfc driver, which creates a sysfs node at /sys/bus/platform/devices/gpmi-nfc.0/nfc_geometry exposing the underlying geometry of the NAND to user space.

The kobs-ng tool accesses this, and looks up:

"Page Size in Bytes"
"Metadata Size in Bytes"
"ECC Chunk Size in Bytes"
"ECC Chunk Count"
"Block Mark Byte Offset"
"Block Mark Bit Offset"

(I think it might only actually be using the last two, but am not completely sure at this point)

With a current kernel, access to the NAND uses the gpmi-nand driver. Almost the exactly identical geometry information is printed out by gpmi_dump_info in gpmi-lib.c, but evidently only in the case of a kernel bug/error.

Is there any way to access this geometry information from user space with the gpmi-nand driver under a current kernel? After a few other minor changes, I was able to successfully get kobs-ng working by hard coding the values based on the output generated while booted under the Freescale kernel. Ideally I'd like to be able to read the necessary information directly from the NAND while booted with a current kernel.

Thanks much…

The current code really does not print out the geometry information directly.

But it's easy to implement it. we can add the dynamic debug code for the gpmi.
If you want to see the geometry infor, you can enable the dynamic debug, and enable it in the kernel cmdline.

i can add it when another gpmi patch is merged:
http://lists.infradead.org/pipermail/linux-mtd/2013-March/046335.html

thanks
Huang Shijie

Thanks much for the quick response and the offer of assistance. Would it be possible to have the information programmatically available such that kobs-ng (or some other application) could read/determine it itself either via a sysfs node like the previous driver or some other method to export the information to user space? A manually triggered debug log would remove the need to boot an older kernel to determine the information, but would still require a user to transcribe the information from the log to kobs-ng. If the sysfs node or other export mechanism was only available if a particular command line option was supplied to the kernel to avoid contaminating the environments of people not interested in such a feature that would be fine.

I assume someday Freescale will update their BSP kernel to a newer version and run into this issue themselves :), so having this information available programmatically in a current kernel will perhaps make their lives easier someday ;).

Thanks again…

The latest kobs-ng uses the same method as the kernel to calculate the necessary parameters. It does not depend on the sysfs node any more. So do not worry about this.

You can download the latest kobs-ng for imx6q from freescale's website(sorry, I do not know the weblink.)

thanks
Huang Shijie

Oh, cool; thanks for the info. I'm working with an imx28, and the version of kobs-ng that comes with the latest BSP for that processor. I'll try to get a hold of the newest kobs-ng and see if that works for imx28 on a current kernel.

Thanks again…

It is really evil to suggest user-space people to use kernel printk's for fetching NAND geometry information. Printk's may change at any time. Tomorrow there may be a clean-up patch which fixes a spelling or improve the grammar, and this may break the apps. Printk's are really not intended to be the kernel<->user-space ABI.

Best Regards,
Artem Bityutskiy