i.MX28 gpmi-nand underlying geometry

i.MX28 gpmi-nand underlying geometry

[Paul B. Henson]

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…

Re: i.MX28 gpmi-nand underlying geometry

[Huang Shijie]

于 2013年03月25日 11:18, Paul B. Henson 写道:
> kernel. Ideally I'd like to be able to read the necessary information 
> directly from the NAND while booted with a current kernel.
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

Re: i.MX28 gpmi-nand underlying geometry

[Paul B. Henson]

On 3/25/2013 12:19 AM, Huang Shijie wrote:

> 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.


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…

Re: i.MX28 gpmi-nand underlying geometry

[Huang Shijie]

于 2013年03月26日 02:39, Paul B. Henson 写道:
> 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. 
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

Re: i.MX28 gpmi-nand underlying geometry

[Paul B. Henson]

On 3/25/2013 7:17 PM, Huang Shijie wrote:

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


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…

Re: i.MX28 gpmi-nand underlying geometry

[Artem Bityutskiy]

On Mon, 2013-03-25 at 15:19 +0800, Huang Shijie wrote:
> 于 2013年03月25日 11:18, Paul B. Henson 写道:
> > kernel. Ideally I'd like to be able to read the necessary information 
> > directly from the NAND while booted with a current kernel.
> 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.

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