This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Kernel Building

Other Parts Discussed in Thread: AM3517

Hi,

I had built the kernel it was running fine. I then changed a value in a driver file (keypad driver) I simply changed a value from 1 to 0.

ARCH and CROSS_COMPILE are set as environment variables.

I then returned to the top of the kernel tree and typed "make".

uImage did not update so I typed "make uImage".

I then booted by loading this kernel via TFTP. The file uncompresses but it hangs after that point.

I reviewed the PSP instructions for building the kernel it suggests a make distclean/make *_defconfig/make process.

Is it not possible to make changes and have it build and link with just the new changes or must the entire kernel be rebuilt from scratch as described in the PSP instructions? 

Thanks,

Ken

PSP 4.2.0.7

AM3517 EVM

  • Hi Ken,

    It depends on whether you build your kernel with the driver "built-in" or loadable as a module. Check your defconfig file (kernel configuration) to see.

    (built-in means you need to rebuild entire kernel, module means you rebuild only the module then use a filesystem to replace the previous module file with a new version to try)

    Lucas

     

     

  • If you are asking about using all three steps (clean/distclean, defconfig, uImage) each time you make changes, you don't have to do that once you have set the defconfig. You can just use make uImage.

  • Thanks Lucas. I understand the difference between a built-in or loadable module. My question is more related to the build: If I "touch" a built-in driver file and then type "make" at the top level will it only rebuild that file and then link?

    Similarly if you chance the .config. Is the build smart enough to know which files were affected and only build them?

  • Hi Ken,

    Yes, make is smart enough to evaluate all levels of dependencies before compiling, comparing timestamps between previously built object files and source files as it goes. 

    The defconfig file is basically a list of make-enviroment variables used during compilation to determine code paths. I'm fairly certain make will not auto-magically pull the defconfig file on modification. 

    Lucas