7i92 firmware issue

I think that message usually means some issue with the script
 I get:

peter@peter-HP-EliteDesk-800-G1-USDT:~/Downloads$ ./getmac
Old MAC Addr: 00601B168000

peter@peter-HP-EliteDesk-800-G1-USDT:~/Downloads$ ./newmac
Old MAC Addr: 00601B168000
New MAC Addr: 00601B160801

Reseting Ethernet CPU
waiting for reset
Old MAC Addr: 00601B160801

what does

./setmac

reply

it should be

peter@peter-HP-EliteDesk-800-G1-USDT:~/Downloads$ ./setmac

Interface not in Environment



 

Works fine.

Sometimes I just have to manually delete the ARP entry for 192.168.1.121

Testing isn't ideal ATM, ping times from the laptop to the card is bad due to having to go through 2 switches (0.244ms best). Setting the MAC works, good ole' 00:de:ad:be:ef:03 that I picked up from a netware 4 instructor.

I'll have to connect things properly & do some testing.

Once again thanks for all the help.

Almost there, just having issues using mesaflash to upload a config.

Erasing goes ok, but hangs at random points when writing.
Loading drivers via halrun works as expected.

Have tried with just writing to internal FPGA config & using openFPGALoader to write to flash.

mesaflash --device 7i92 --addr 10.10.10.10 --fix-boot-block --write some_file.bit

Had no issues with the EPP board, load into fpga config then writing with mesaflash was no issue.
Is there a particular version of etherhm2 (16,17 or 18) that needs to be used ?
Due to pin allocatons I have to build my own bitfiles.

My guess would be some Ethernet data <--> FPGA transfer issue.
Does the Ethernet chip interrupt pin (EINT) have a pullup?
Drive = 4 on ECLK (for series termination)?

The firmware version is not really important as the fixes are minor
(LED issues, Addition of netmask, addition of MAC mask)
 

I thought EINT might be the issue, there's a 1k pullup to 3.3v, the top 8 data lines have a 1k pull down.

Might be C5 around the L1 inductor, I installed a 100nf cap instead of a 4.7uf.

I don't know if that will make a lot of difference.

I've run a config, no hardware connected to the board yet, but no errors. Tho I assume writing to the flash is more of a load. It's bound to be something stupid on my behalf.

The major difference is the WP on the flash is just held high, any chance that the circuit around the WP on the flash is causing the issue, there's no reset device connected. Tho the EPP & SPI based on the 7c81 have been the same.

If its just a flash issue, ( normal Ethernet comms  are reliable )
It may possibly be a a compatibility issue or perhaps signal
integrity or some other flash EEPROM connection issue.

I think it might be a comms issue relating to the filtering issue around the internal voltage regs. All the ref designs I've seen use 4.7uf cap with the 2 100nf with the inductor. I'll have to wait for some caps to come in.

Using openFGPALoader with the flash over SPI works fine (load a config directly to the FPGA then communicates with the FPGA ), so I can reliably write to the flash.

Looking at a session with wireshark, the board stops comms first. And the time it takes to happen can be kind of random. I'm prepared to accept that the design may not just work due to "Reasons" (bad layout, signal trace lengths, lack of knowledge of my behalf). I may have to read the mesaflash code and work out the programming protocol to get a better understanding.