How to add support for SPI NOR Flash for a single build

TLDR: I want to add support for a SPI NOR chip in my own copy of the source before I ask for it to be patched to the kernel, so I can get a working build now. I cannot find directions or hints from the code anywhere....

I am trying to use some Winbond chips I bought recently, but the JEDEC ID is not recognized...

Message from kernel is:

m25p80 spi0.0: unrecognized JEDEC id bytes: ef, 70, 17

The chip is W25Q64JV-SIM
I am building for MIPS, ar71xx/tiny

(This is a flash upgrade from 4 MB to 8 MB
I recompiled u-boot and it comes up fine)

I realized that there is a file in the build_dir that contains the info for all supported SPI NOR chips...but this is after you generate at least one build. I can't find anything related on github except for .patch files which I don't really understand. But I do understand that the kernel needs to be rebuilt to change chips supported...

for my situation, after a build I ran:

find . -name spi-nor.c

and the reply was:


After looking through that file I found the lines:

{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
{ "w25q128jv", INFO(0xef7018, 0, 64 * 1024, 256,

The funny thing is, the JEDEC ID of ef, 40, 17 is indeed for the JV series...but only the chips that end with -IQ...

From the datasheet:
W25Q64JV-_IQ: 4017h
W25Q64JV-_IM: 7017h

I bought the -SIM package because (at the time) I was worried I would be stuck in Quad SPI mode...and that I needed the /WP pin to write. That seems to not be true after reading the datasheet more carefully...

I attempted to add the following line to spi-nor.c, since it is exactly the same as the W25Q128JV but half the size.

{ "w25q64jv", INFO(0xef7017, 0, 64 * 1024, 128, SECT_4K) },

and then proceed as usual:

make menuconfig
nohup make V=s &

Build was successful...but I get the same kernel message, and MTD parts are never found, so rootfs cannot mount...

What am I missing and why is this so complicated?

Do I have to run make distclean and start over? or remove staging_dir?

Downloaded sources are best patched, rather than edited. The build system often re-extracts and patches build-directory edits into oblivion.

See what seem to be two, nearly identical pages:

Also check for upstream changes and/or submitted patches.

Edit: I didn't see anything in Linux v5.1-rc1

1 Like

Thanks for the quick reply. I suppose I will learn how to make a patch.

What puzzles me though, is that the line I inserted into spi-nor.c is still there...even after the build and make clean. I would think if the build system rejects a raw edit, that it would disappear, no?

I never try to overthink how make works, especially in context of a very sophisticated build system!!

So...last detail...

When I look at other similar patches I see the following:

--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1165,6 +1165,11 @@ static const struct flash_info spi_nor_i

Seems to be referring to a copy of spi-nor.c that is not in the build_dir after a build....but I can't spi-nor.c in the source until at least one build is done. Like I said, the only result of find for spi-nor.c was in the build_dir folder....

I guess the question is, what do the folders or roots "a" and "b" represent?

a and b are the extraction root of the source, before and after the change. Something like build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx/linux-4.19.25/ in the build system (with your architcture, platform and Linux version).

Rather than editing the patch manually, you can set up for quilt, add a new patch, edit the file, refresh the patch, refresh the build system (which copies it to the patches directory), add it to your git branch, then build. With it in the proper patches directory, it will be applied at build time.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.