Is it possible to debug kernel modules with git bisect?
Not easily, you'd end up with huge patch stacks instead.
Sadly most devices covered by OpenWrt need a huge amount of target specific patches to work, some of those are backports from more current kernels, some are in the review process for being merged in the future, others do the work needed, but have no chance at all to be merged - and on top of that there are also some generic patches needed, be it for allowing certain functionality, improving performance on low-end devices or hacks to reduce kernel size (when upstream kernel developers think of 'embedded', they usually have phones with flash sizes measured in tens of GB and RAM sizes above 1 GB in mind, patches necessary to make 4/16 device 'work' are usually not very welcome). Whenever to do change between upstream version, you need to rebase this rather huge patch stack along - which is not quite for the faint of heart.
3 Likes
Thanks! 
So even if I only want basic functionality like UART and check where my spi driver fails, I can not do this without re-basing all patches, since the normal kernel would not fit on my device?
Yes.
As many/most of the OpenWrt patches are hardware related, it makes no sense to test kernel without them (and with most routers, the kernel might not even work).
If you are talking about minor incremental bump, like 5.4.64 to 5.4.66, you could try manually download a kernel source snapshot from middle of those commits (based on kernel.org stable branch commit history), extract the sources and see if the patches still apply. In practice the easiest might be to rename the bisect source archive properly and change version & hash accordingly in
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/kernel-version.mk;h=5b9a6ad6d8ec5757deab25e4feb81a079dbe9139;hb=HEAD
But if you need to bisect major jump like from 4.19.x to 5.4.x, forget it.
Sad, but a fact of life.
2 Likes
I tried to copy the spi driver from 5.9 kernel to 5.4 version. Did not work as expected. 
Kernel Panic...
Do u have some examples of that patches that are not merged?
I'm just trying to debug a jffs2 error that pops up with linux kernel 5.4 but not with 4.19. So I accomplished to exchange the spi-nor.{c,h} from 4.19 in 5.4 kernel. Same error. So I try now to exchange jffs2 from 4.19 with 5.4 kernel. But this is so complicated since a lot is changing... 
Do u have further ideas?
I seriously don't believe that the SPI-NOR driver is at fault here, SPI ath79 driver also does not look like a possible suspect as all it had done between 4.19 and 5.4 is CS was converted to a current framework.
Do your devices maybe use 4K sectors?
Not sure. How can I check that?
Looked into the 5.4 config but there is not the config flag CONFIG_MTD_SPI_NOR_USE_4K_SECTORS enabled... ?
Should I enable it?
No, I was asking because if they use 4K sectors than that got broken in 5.4
Can I try something different?
Take a look at the JFFS2 changes, this one looks somewhat related:
Yep. Already saw this. I tried yesterday to add a patchset by adding all patches for the jffs2. Was not working. xD I will try this single patch. 
Well, they backported most of the fixes back to 5.4 tree anyway
1 Like
Ported the jffs2 commit back and will try the fix if it helps.
Why staying on kernel 5.4 if most of the changes are backported? ^^
Because bumping to 5.9 involves porting hundreds of OpenWrt specific generic patches.
The same errors are still happening with that "Newly-erased block contained word".
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...
Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
Is that correct with umount can not unmount /dev?
Special Firmware Note: AirOS XM.v5.5.X images used U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07). The OpenWRT image can be successfully flashed onto these versions of firmware. However, in July 2015 Ubiquiti released a new version of firmware XM.v5.6.X. With this firmware a new U-Boot version was released, U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50). The newer U-Boot version changes the memory size and starting address for rootfs, cfg, and EEPROM. LOADING AN OPENWRT IMAGE ON A U-Boot 1.1.4.2-s956 WILL CAUSE THE DEVICE TO BE BRICKED!!!
https://dev.archive.openwrt.org/ticket/20982
Hmmmm
Probably with new kernel partition layout changed (since kenerl gets bigger) and I need to flash another u-boot?
That is normal