On Wed, Jun 18, 2014 at 09:05:56AM +0200, Remi Locherer wrote: > I had my athn card working fine in my APU board with -current amd64. > But then after a reboot athn was not there anymore. The dmesg showed that > it had the id 0xff1c. After the next reboot it attached again normaly > (dmesg below from the working state). > > While searching for the ID 0xff1c I found something in the openwrt ticket > system but could not track it down do an actual commit to linux. > https://dev.openwrt.org/ticket/9991
Adrian Chadd explains the problem as follows. In short: If you only see this problem with APU boards, please talk to pcengines. [[[ Hi, 0xffXX on those chips (and 0xabcd on ar9380 and later) is what's in the hardware before it gets set up during reset. It's what was used during FPGA emulation and made it onto the chips. The EEPROM (or flash, in the case of the MIPS AP boards) has the PCI ID and some other PCI settings. The hardware reads the EEPROM just after a PCI reset and programs the PCI ID with the real ID. The driver code has to read the NOR flash to program in the PCI ID during the driver load. I'm assuming this is a PC, not a MIPS AP. So if you're seeing 0xffXX on a MIPS AP board, it means you're missing some PCI/PCIe glue in your Atheros MIPS code to suck this stuff in at startup time. If you're seeing 0xffXX on a PC, then the PCI reset isn't finishing correctly or is timed bad (eg it's too short, or there's a second PCI reset after the first, but it's happening too quickly) and it's fucking things up. No, you don't want to detect on 0xffXX. You really want to figure out why the reset isn't working right. -a ]]]
