CODEWITHSUNDEEP
linux-kernelembedded-linuxflash-memory
Abhi
Abhi

Reputation: 236

mtd driver update with older kernel

I am using Spansion 64MB NOR flash (via mtd/cfi_cmdset_0002) and am facing issue related to flash erase operations.

I have Linux Kernel 2.6.10 and by comparing the code of /drivers/mtd between 2.6.10 and 3.11.1

There were a few fixes given for /drivers/mtd/chips/cfi_cmdset_0002.c) and othet mtd files as well for checking bit toggles, change in delay while flash erase and enabling and disabling VPP for the flash operations.

I have done changes for files under drivers/mtd/chips but when checked the changes for /mtd files (like mtdpart,mtdcore,cmdlinepart etc) I can see a huge amount of porting required and seems porting the kernel itself might be required. Is there a way around this problem, because i dont want to change the kernel but want to upgrade the mtd driver code to as best as possible with 2.6.10 itself?

Also i wanted to know where to find the change logs for the mtd code from 2.6.10 to 3.11.1 (i could not locate it, nor the revision history in these files are updated for changes)

Upvotes: 1

Views: 603

Answers (1)

artless-noise-bye-due2AI
artless-noise-bye-due2AI

Reputation: 22469

Is there a way around this problem, because i dont want to change the kernel but want to upgrade the mtd driver code to as best as possible with 2.6.10 itself?

Generally all of the commits to Linux try to be atomic pieces that implement a chunk of functionality. Anyone who has coded a bit will know that some changes are very isolated and others are systemic. Ie, you have a specific functional changes and infra-structure changes. If you want to get all of the 3.11.1 changes, you have to get 3.11.1. You need to decide which infra-structure changes you don't want.

There are some UbiFs backports at infradead.org, for instance the UbiFs 2.6.32 backport contains patches for the MTD layer up to about Linux 3.0. Taking these changes and applying them to your tree should be less of an issue. Linux 2.6.34 and 2.6.32 have better back ports; if you could upgrade to that version there is less that has to be done. It is fairly simple to back-port all changes that are driver or chip set specific. Occasionally, there are infra-structure changes that make the back port difficult or impossible. For example, a function is not allowed to be called from interrupt context in an older kernel, but can in a newer version. Checkout some of the git repositories at infradead, one may fit your situation.

Generally, I go through the changes and only back port those I need. You can get patches for a single file with git format-patch verA..verB file and then apply them with git am. It is pretty trivial to apply 10-20 and then do a build/regression test. As you have to throw away patches, the harder and harder it will become to merge the later patches.

Also i wanted to know where to find the change logs for the mtd code from 2.6.10 to 3.11.1 (i could not locate it, nor the revision history in these files are updated for changes)

Just go to the directory and use git log --follow .; you need the --follow options for the occasions that files have moved; at least I think that will work. If not, you can use git to checkout the version just before the move with *SHA_ID~1* and use the detached head to get the history before the move.

Upvotes: 1

Related Questions