>>>>> "Jochen" == Jochen Friedrich <[email protected]> writes:
Jochen> Hi Russell, >> By judicious application of printk's (note that in order to get the >> console back for the WGT634U to see them, I had to revert r22663) I >> managed to figure out what is visible, and now have at least >> broadcom-diag detecting the board again with this patch: [...] Jochen> Thanks a lot. I'm going to test this on my WGT634U. Curiously, the WGT634U does not seem to trigger get_router() in target/linux/brcm47xx/files-2.6.34/drivers/mtd/maps/bcm47xx-flash.c, at least I didn't get any printk's out of it. The get_router() function is called from init_mtd_partitions(). It appears as the normal nvram_get function is just matching to the section of flash that it finds with the FLSH header magic. The WGT has one of those sections, at offset 0x018000 of mtdblock4, but the only value is the sdram_ncdl and the meat of the board information is located at offset 0x01e000 of mtdblock4 and has no FLSH magic. I have no idea how uniquely you can identify the WGT based on those values though. The vanilla linux kernel guesses at identifying the WGT just based on Netgear allocated macaddrs. Seems like there ought to be a more robust way. -- Russell Senior ``I have nine fingers; you have ten.'' [email protected] _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
