After some reading in various topics I decided to upgrade memories in my TL-MR11U (the chinese version of the TL-MR3040). There are good topics on that and they all stick to a 16MB flash. I figured I would use a bigger flash, reasoning that the AR9331 would need the first MBs for booting, and the kernel would take over by using MTD (which does not rely on a hardware FTL).
Well, modding to 64MB DRAM went well, the 32MB flash failed at first because openwrt (mktplinkpart.c) failed to find the TP-link header.
Odd... but not - here's why: the m25p80 MTD driver detects the >16 MB flash so it switches to 4-byte addressing mode. That, however, is not supported by the hardware FTL in the ar9331. Not a problem normally, because the kernel uses SPI (it did to figure out the make and model of the flash chip).
Yet, the maintainer for the ar9331 spi driver optimized spi access by determining if it is a data read and if so, uses memcpy() to transfer data using the (much faster) hardware FTL.
This is fixable by modifying some struct member ( is_flash) which would cause that driver to refrain from memcpy and use spi instead. I actually modified the driver to always use the spi routines. Additionally, I modified the m25p80.c driver to reset the chip to 3-byte addressing mode on unregistering the driver, so the device can boot after reset.
So now I have a operational OpenWRT image with 32 Mbyte of flash. There is just one problem: no wireless because the ath9k driver cannot load the ART data onto the hardware.
I did make modifications to the u-boot, so my ART partition is now at where the 64k uboot-env used to be - also hoping that the kernel driver would somehow receive a copy of this ART partition by using the MTD, but it appears it is not so.
At this moment, I am considering two options to get wireless up again:
1) make the ATH9k kernel driver retrieve a copy of the MTD partition, store it in kernel memory and use it as a reference, or
2) make u-boot initialize the wireless - code for this would be similar to dev-init in ar7240-pci.c. I will try the u-boot version developed by pepe2k tonight...
I took a look at the ath9k kernel driver, but I can't figure out how it learns to read the eeprom and from what location. The "ahb.c" file appears to contains some functions that hint on the memory mapped access, but it receives the base address from somewhere else.
Any insights or suggestions on how to get the ART data into the wireless driver are highly appreciated!