fmc_basic_peripheral: update readme for kicad 10 and m24c64 fru programming

Signed-off-by: Huang Rui <vowstar@gmail.com>

Author: vowstar

fmc_basic_peripheral/README.md

@@ -8,7 +8,7 @@ of the SoC.
 
 ## Preparation
 
-Install kicad 8, cmake, ninja, frugy.
+Install kicad 10, cmake, ninja, frugy.
 
 ## Precautions
 
@@ -45,12 +45,23 @@ cmake --build build --target production
 
 Use a CH341A USB-to-I2C adapter (PID `1a86:5512`, EPP/MEM/I2C mode) with
 [ch341eeprom](https://github.com/commandtab/ch341eeprom). Wire `SDA`, `SCL`,
-`VCC` (3.3V) and `GND` to the on-board M24C02, and pull `WP` to GND.
+`VCC` (3.3V) and `GND` to the on-board M24C64, and pull `WP` to GND.
 
 ```bash
-ch341eeprom -v -s 24c02 -w build/fmc_fru_eeprom.bin
-ch341eeprom -v -s 24c02 -V build/fmc_fru_eeprom.bin
+ch341eeprom -s 24c64 -e
+ch341eeprom -s 24c64 -w build/fmc_fru_eeprom.bin
+ch341eeprom -s 24c64 -V build/fmc_fru_eeprom.bin
 ```
 
-The verifier reports a mismatch at offset 238 because the FRU image is 238
-bytes while the EEPROM is padded to 256 — the FRU data itself is correct.
+`ch341eeprom` auto-pads the 2 KiB image with `0xFF` to the full 8 KiB chip
+size. The verifier then reports a mismatch at offset 2048 (`EEPROM: FF,
+file: 00`); this is a tool quirk (file tail is compared as `0x00` against the
+chip's `0xFF` padding), not a data error. To check the FRU bytes directly:
+
+```bash
+ch341eeprom -s 24c64 -r /tmp/dump.bin
+cmp -n 2048 /tmp/dump.bin build/fmc_fru_eeprom.bin
+```
+
+Do not pass `-s 24c02` to the M24C64; the chips use different address widths
+(16-bit vs 8-bit), so the writes would scatter across the chip.