2013/3/1 Tijs Van Buggenhout <t...@able.be>: > On Friday 01 March 2013 19:44:28 Fiach Antaw wrote: >> > For board detection have a look at new detection code (in both 3.8, 3.6) >> > https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-3.8/26 >> > 0-MIPS-BCM47XX-add-board-detection.patch and the backup detection code in >> > https://dev.openwrt.org/browser/trunk/package/broadcom-diag/src/diag.c >> >> Ah, I saw the 260- board detection patch but I didn't know that diag.c >> did it's own board detection, thanks. >> >> > boardnum=G33779F3NR -> unique >> > >> > I suppose the boardnum nvram variable makes the most sense. (or a >> > combination of boardrev and boardtype) >> >> I thought that at first too, but it matches the serial number printed >> on the casing (along with the wifi/lan MAC IDs and such), so I'm >> thinking it's unit-specific. At the moment I'm just checking boardtype >> and boardrev, and will probably add a check for the presence of >> boardnum even if I can't use the value itself for detection. >> >> > Don't forget to save board_data or other important partitions before you >> > flash :D >> >> I just saved an image of the whole flash (0x1c000000-0x1d000000) with >> the CFE's 'save' command. I've been working under the assumption that >> if worst comes to worst I can just use JTAG to flash that back on >> (since I've worked out the JTAG pinouts and have a slow-but-workable >> Bus Pirate with OpenOCD support), is there anything else I'd need? > > Maybe you can try a tftp boot of the new openwrt (elf) image via CFE, avoiding > to flash the device? > > http://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm47xx#network.boot
Try that and verify if partition "board_data" was detected by the Linux. I suggest building 3.8 based bcm47xx firmware, as it uses "bcm47xxpart" driver which should handle board_data (detect it). -- Rafał _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
