machine: add the 2G5F4_10G2_V1.01 (HYWS-SGT0204S) target

The hongyavision HYWS-SGT0204S is sold as an unmanaged 4x2.5G + 2x10G SFP+
switch and carries the 2G5F4_10G2_V1.01 marking on the PCB. It is a sibling of
the KP-9000-6XH-X2 (2M-PCB43-V1.1), so machine/2G5F4_10G2_V1_01.c is that board
definition with these changes:

- The two SFP+ cages (physical ports 5 and 6) are wired the other way round:
  physical 5 is on SDS1 with GPIO30/GPIO37, physical 6 on SDS0 with
  GPIO50/GPIO10. Copper ports 1-4 match the KP-9000 layout.
- No reset button is fitted and the case has no opening for one, so reset_pin
  is GPIO_NA. GPIO54, the reset pin on the KP-9000 layout, reads as permanently
  pressed here.
- The board definition sets flash_sio, so the flash is read with single-IO: the
  fitted 512 KB Bright Moon T25S40 cannot be read in DIO mode on this board, an
  image that leaves DIO enabled does not come up at all, while the same image
  with single-IO boots and runs normally (two units).
- The board is added to the machine_custom_init() group that sets
  LED_GLB_IO_EN bit 6, otherwise the RTL837x "solid" conditions (LINK/speed)
  never drive the LEDs and the 2.5G LED glows faintly at 100M/1000M.

flash_sio is a new field of struct machine that rtlplayground.c hands to
flash_init(); only this board sets it, every other machine keeps DIO. It costs
management-plane speed only, the ASIC keeps forwarding in hardware.

The stock firmware runs a factory test console on the serial header at 9600
baud, whose silkscreen labels are shifted by one pin.

Verified: warning-free build, `make machine_check` passes for every target, the
host tests pass, and a control build of this target without the LED hook differs
from the KP-9000-6XH_X2_V1_1 image in 44 bytes: all inside the machine
description (including flash_sio) and the image CRC16, nothing else in the
firmware moved. On the board the single-IO image boots and runs on two units;
port order, SFP cages and LED behaviour come from the machine definition
verified on this board earlier.

machine/2G5F4_10G2_V1_01.c

@@ -0,0 +1,54 @@
+#include "machine_defs.h"
+
+__code const struct machine machine = {
+	.machine_name = MACHINE_MODEL,
+	.isRTL8373 = 0,
+	.min_port = 3,
+	.max_port = 8,
+	.n_sfp = 2,
+	/* Same 2M-PCB43-V1.1 board family as the KP-9000-6XH-X2 (see
+	 * machine/KP_9000_6XHML_X2.c), but the two SFP+ cages (physical ports 5 and
+	 * 6) are wired the other way round: physical 5 is on SDS1, physical 6 on
+	 * SDS0. Copper ports 1-4 match the KP-9000 layout. */
+	.log_to_phys_port = {0, 0, 0, 6, 1, 2, 3, 4, 5},
+	.phys_to_log_port = {4, 5, 6, 7, 8, 3, 0, 0, 0},
+	.is_sfp = {0, 0, 0, 2, 0, 0, 0, 0, 1},
+	// Left SFP cage (physical port 5) = SDS1
+	.sfp_port[0].pin_detect = GPIO30_ACL_BIT3_EN,
+	.sfp_port[0].pin_los = GPIO37,
+	.sfp_port[0].pin_tx_disable = GPIO_NA,
+	.sfp_port[0].sds = 1,
+	.sfp_port[0].i2c = I2CBUS( GPIO39_I2C_SDA4, GPIO40_I2C_SCL3_MDC1 ),
+	// Right SFP cage (physical port 6) = SDS0
+	.sfp_port[1].pin_detect = GPIO50_I2C_SCL2_UART1_TX,
+	.sfp_port[1].pin_los = GPIO10_LED10,
+	.sfp_port[1].pin_tx_disable = GPIO_NA,
+	.sfp_port[1].sds = 0,
+	.sfp_port[1].i2c = I2CBUS( GPIO41_I2C_SDA3_MDIO1, GPIO40_I2C_SCL3_MDC1 ),
+	/* The board has a 3-hole reset button footprint, but it is unpopulated and
+	 * the case has no opening for it, so reset_pin stays GPIO_NA. GPIO54, the
+	 * reset pin on the KP-9000 layout, reads as permanently pressed here. */
+	.reset_pin = GPIO_NA,
+	/* The fitted T25S40 does not work in DIO mode on this board, so read the flash
+	 * with single-IO; see doc/devices/2G5F4_10G2_V1.01.md. */
+	.flash_sio = 1,
+	.high_leds = { .mux = LED_27 | LED_29, .enable = LED_28_SYS | LED_29 },
+	.port_led_set = { 0, 0, 0, 0, 0, 0, 0, 0, 0},
+	/* Conditions for LED on:
+	 * dual led orange: ledset_0 & ledset_2
+	 * dual led green: ledset_2 & !ledset_0
+	 * single right led green: ledset_0 & !ledset_1
+	 *
+	 * Measured on this board: LED-ID0 is the copper blue LED, LED-ID1 the
+	 * copper white one (setting LED-ID0 to 0 killed blue while leaving white on
+	 * at 2.5G only) and LED-ID2 carries the SFP single LED. The "solid"
+	 * conditions (LINK/speed) barely drive the LEDs here and ACT is what
+	 * actually lights them, which is why the white LED used to glow faintly at
+	 * non-2.5G speeds; the fix for that is LED_GLB_IO_EN bit 6, set in
+	 * machine_init.c. */
+	.led_sets = { { LEDS_2G5 | LEDS_1G | LEDS_100M | LEDS_10M | LEDS_LINK | LEDS_ACT | LEDS_10G,
+			LEDS_2G5 | LEDS_LINK | LEDS_10G,
+			LEDS_1G | LEDS_LINK,
+			0 },
+		    },
+};