AMD/Fujitsu Flash Chip Not Supported
|Reported by:||eapache@…||Owned by:||developers|
|Priority:||normal||Milestone:||Barrier Breaker 14.07|
OpenWRT will not boot successfully on a WRT310n router because the flash chip is not supported.
I have attached the serial dump of the boot process, as well as a source file from dd-wrt that appears to be relevant.
As far as I can tell, the flash chip itself is detected properly in
lines 150-152 of the serial dump. At this point, the chip is passed to gen_probe's function mtd_do_chip_probe (/drivers/mtd/chips/gen_probe.c line 21) to find the proper command-set and driver, which is then supposed to be passed to do_map_probe which actually loads the driver and inits the chip.
However mtd_do_chip_probe fails to determine anything useful and returns NULL, thus causing do_map_probe to fail, leading to the kernel panic a few seconds later.
Tracing the error in gen_probe, it seems that check_cmd_set (line 233) is returning NULL at lines 35 and 37. The serial dump defines the chip as "AMD/Fujitsu Extended" which, according to vendorname
(/drivers/mtd/chips/cfi_probe.c line 277) means that a type of P_ID_AMD_EXT was detected. In /include/linux/mtd/cfi.h, line 249, this is #defined as 0x0004. So check_cmd_set should be calling and returning the value from cfi_cmdset_unknown (call line 259, def line 202).
Since we don't see the notice in the serial dump about "Support for command set not present", this means that cfi_cmdset_unknown has to be returning on line 225. The variable returned is only set once by probe_function on line 222, which is a pointer to an apparently empty or non-existent function.
Having looked briefly at the dd-wrt source, they appear to support this chip via the attached source file (drivers/mtd/chips/amd_flash.c). I have not been able to determine how this hooks into their gen_probe.c however, so I could be wrong.