Anyone still using Mikrotik rb532A? (2006, mips32le router)

[DiTBho]

Anyway, very happy for all the things you can do with 9 network ports 

[Nominal Animal]

Ah-ha, so it is just the PCI I/O bar size calculation that was the issue. 

Have you checked UDP traffic, using a short cable, nc/ncat (or bash script using /dev/udp/address/port) and link-local/fixed-IP addressing, to verify the Ethernet ports work?

The hack is incorrect, because it adds to all bridges, including the root bridge; and root bridges are special as they may not be sizable.

Also, the kernel parameter to test (me fail, forgot pci= prefix ) is actually
    pci=hpiosize=8192

If the log does not contain a max bus depth: N pci_try_num: N line, then the kernel just doesn't trigger reallocation of resources, and
    pci=realloc=on
might fix it.

It is possible you need both, i.e. pci=realloc=on,hpiosize=8192 might fix it.

(If so, then it is a system configuration matter, not an actual bug.)

If none of the above on an unpatched kernel fixes the issue, adding
    pci_info(bus->self, "for bridge window %pR, size %llu, size1 %llu, min_size %llu, add_size %llu, children_add_size %llu\n", b_res, (unsigned long long)size, (unsigned long long)size1, (unsigned long long)min_size, (unsigned long long)add_size, (unsigned long long)children_add_size);
to linux-6.0.2/drivers/pci/setup-bus.c:pbus_size_io() line 922, and
    pci_info(bus->self, "bridge window at %pR\n", b_res);
to just before the end of that same function, and seeing all pci 0000: lines from the boot log, would help pinpoint the issue.

(If there is e.g. a pci: 0000:00:06.00 bridge window at [io  0x0000-0x05ff] (or similar, with a 0x600 aperture), then there is a bug in how bridge I/O address space requirement is calculated (not taking correctly into account that each device needs their own window in the bridge).  If there is only one pci: 0000:00:06.00 bridge window at [io  0x0000-0x0fff] (or similar, with a 0x1000 aperture), and pci=realloc=on,hpiosize=8192 does not fix it, then the reallocation mechanism doesn't get triggered at all, and the fix is a simple early PCI quirk to PCI ID 3388:0031 for rb564.)

If the above does not add light to the matter, the crude but minimally intrusive way to fix this would be to reuse the hotplug default allocation mechanism:

Code: [Select]

--- linux-6.0.2.original/drivers/pci/pci.c 2025-02-16 07:18:17.722611122 +0200
+++ linux-6.0.2/drivers/pci/pci.c 2025-02-16 12:12:42.349706176 +0200
@@ -84,6 +84,10 @@
 int pci_domains_supported = 1;
 #endif
 
+#define DEFAULT_BRIDGE_IO_SIZE (0)
+/* pci=bridgeiosize=nn can override this */
+unsigned long pci_bridge_io_size = DEFAULT_BRIDGE_IO_SIZE;
+
 #define DEFAULT_CARDBUS_IO_SIZE (256)
 #define DEFAULT_CARDBUS_MEM_SIZE (64*1024*1024)
 /* pci=cbmemsize=nnM,cbiosize=nn can override this */
@@ -93,7 +97,7 @@
 #define DEFAULT_HOTPLUG_IO_SIZE (256)
 #define DEFAULT_HOTPLUG_MMIO_SIZE (2*1024*1024)
 #define DEFAULT_HOTPLUG_MMIO_PREF_SIZE (2*1024*1024)
-/* hpiosize=nn can override this */
+/* pci=hpiosize=nn can override this */
 unsigned long pci_hotplug_io_size  = DEFAULT_HOTPLUG_IO_SIZE;
 /*
  * pci=hpmmiosize=nnM overrides non-prefetchable MMIO size,
@@ -6870,6 +6874,8 @@
  resource_alignment_param = str + 19;
  } else if (!strncmp(str, "ecrc=", 5)) {
  pcie_ecrc_get_policy(str + 5);
+ } else if (!strncmp(str, "bridgeiosize=", 13)) {
+ pci_bridge_io_size = memparse(str + 13, &str);
  } else if (!strncmp(str, "hpiosize=", 9)) {
  pci_hotplug_io_size = memparse(str + 9, &str);
  } else if (!strncmp(str, "hpmmiosize=", 11)) {

--- linux-6.0.2.original/drivers/pci/pci.h 2025-02-16 12:54:42.204863718 +0200
+++ linux-6.0.2/drivers/pci/pci.h 2025-02-16 12:55:03.924903542 +0200
@@ -178,6 +178,8 @@
 extern const struct device_type pci_dev_type;
 extern const struct attribute_group *pci_bus_groups[];
 
+extern unsigned long pci_bridge_io_size;
+
 extern unsigned long pci_hotplug_io_size;
 extern unsigned long pci_hotplug_mmio_size;
 extern unsigned long pci_hotplug_mmio_pref_size;

--- linux-6.0.2.original/drivers/pci/setup-bus.c 2025-02-16 07:19:07.278591151 +0200
+++ linux-6.0.2/drivers/pci/setup-bus.c 2025-02-16 12:19:05.474162483 +0200
@@ -1252,6 +1252,9 @@
  additional_io_size  = pci_hotplug_io_size;
  additional_mmio_size = pci_hotplug_mmio_size;
  additional_mmio_pref_size = pci_hotplug_mmio_pref_size;
+ } else {
+ if (bus->self->io_window)
+ additional_io_size = pci_bridge_io_size;
  }
  fallthrough;
  default:

so that to apply the fix, you supply pci=bridgeiosize=8192 to the kernel command line, or define the DEFAULT_BRIDGE_IO_SIZE to (8192), so that each non-root, non-hotplug, non-cardbus PCI bridge that can do an I/O window always gets one of at least 8k wide.

[DiTBho]

Ah-ha, so it is just the PCI I/O bar size calculation that was the issue. 

Have you checked UDP traffic, using a short cable, nc/ncat (or bash script using /dev/udp/address/port) and link-local/fixed-IP addressing, to verify the Ethernet ports work?

Yup, it's start mooooooooooving 

I tried that weird hack, because other tries failed.
Not yet tested with a physical cable, because I am remotely accessing the router.
I can reset, power cycle, but I need to go physically there.
I am already ready with the bridge support + a FON2 machine to test each rb564 port!
Will be likely done on Tuesday 

[DiTBho]

Code: [Select]

./mybuild-2024 6 5
[step6] tools
[step5] apply each patch
applying patches_my/NA_pci_02.patch ... success
~ drivers/pci/pci.c
~ drivers/pci/pci.h
~ drivers/pci/setup-bus.c


Code: [Select]

PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [111d:0000] type 00 class 0x000000
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x07ffffff pref]
pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:02.0: [1106:3106] type 00 class 0x020000
pci 0000:00:02.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:00:02.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:00:03.0: [1106:3106] type 00 class 0x020000
pci 0000:00:03.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:00:03.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:00:03.0: supports D1 D2
pci 0000:00:03.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:00:04.0: [13a3:0020] type 00 class 0x0b4000
pci 0000:00:04.0: reg 0x10: [mem 0x00000000-0x00000fff]
pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x00001fff]
pci 0000:00:04.0: reg 0x18: [mem 0x00000000-0x00007fff]
pci 0000:00:06.0: [3388:0031] type 01 class 0x060400
pci 0000:00:06.0: supports D1 D2
pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci_bus 0000:01: extended config space not accessible
pci 0000:01:02.0: [1106:3106] type 00 class 0x020000
pci 0000:01:02.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:02.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:02.0: supports D1 D2
pci 0000:01:02.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:03.0: [1106:3106] type 00 class 0x020000
pci 0000:01:03.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:03.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:03.0: supports D1 D2
pci 0000:01:03.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:04.0: [1106:3106] type 00 class 0x020000
pci 0000:01:04.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:04.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:04.0: supports D1 D2
pci 0000:01:04.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:05.0: [1106:3106] type 00 class 0x020000
pci 0000:01:05.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:05.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:05.0: supports D1 D2
pci 0000:01:05.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:06.0: [1106:3106] type 00 class 0x020000
pci 0000:01:06.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:06.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:06.0: supports D1 D2
pci 0000:01:06.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:07.0: [1106:3106] type 00 class 0x020000
pci 0000:01:07.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:07.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:07.0: supports D1 D2
pci 0000:01:07.0: PME# supported from D1 D2 D3hot D3cold
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
pci 0000:00:06.0: (1) for bridge window [io  0x0000], size 1536, size1 0, min_size 8192, add_size 8192, children_add_size 0
pci 0000:00:06.0: (2) for bridge window [io  0x0000], size 1536, size1 8192, min_size 8192, add_size 8192, children_add_size 0
pci 0000:00:06.0: bridge window at [io  0x0000]
pci 0000:00:06.0: BAR 8: assigned [mem 0x50000000-0x500fffff]
pci 0000:00:04.0: BAR 2: assigned [mem 0x50100000-0x50107fff]
pci 0000:00:04.0: BAR 1: assigned [mem 0x50108000-0x50109fff]
pci 0000:00:04.0: BAR 0: assigned [mem 0x5010a000-0x5010afff]
pci 0000:00:06.0: BAR 7: assigned [io  0x18800000-0x18801fff]
pci 0000:00:02.0: BAR 0: assigned [io  0x18802000-0x188020ff]
pci 0000:00:02.0: BAR 1: assigned [mem 0x5010b000-0x5010b0ff]
pci 0000:00:03.0: BAR 0: assigned [io  0x18802400-0x188024ff]
pci 0000:00:03.0: BAR 1: assigned [mem 0x5010b100-0x5010b1ff]
pci 0000:01:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
pci 0000:01:02.0: BAR 1: assigned [mem 0x50000000-0x500000ff]
pci 0000:01:03.0: BAR 0: assigned [io  0x18800400-0x188004ff]
pci 0000:01:03.0: BAR 1: assigned [mem 0x50000100-0x500001ff]
pci 0000:01:04.0: BAR 0: assigned [io  0x18800800-0x188008ff]
pci 0000:01:04.0: BAR 1: assigned [mem 0x50000200-0x500002ff]
pci 0000:01:05.0: BAR 0: assigned [io  0x18800c00-0x18800cff]
pci 0000:01:05.0: BAR 1: assigned [mem 0x50000300-0x500003ff]
pci 0000:01:06.0: BAR 0: assigned [io  0x18801000-0x188010ff]
pci 0000:01:06.0: BAR 1: assigned [mem 0x50000400-0x500004ff]
pci 0000:01:07.0: BAR 0: assigned [io  0x18801400-0x188014ff]
pci 0000:01:07.0: BAR 1: assigned [mem 0x50000500-0x500005ff]
pci 0000:00:06.0: PCI bridge to [bus 01]
pci 0000:00:06.0:   bridge window [io  0x18800000-0x18801fff]
pci 0000:00:06.0:   bridge window [mem 0x50000000-0x500fffff]


Code: [Select]

        /* suppa */ pci_info(bus->self, "(1) for bridge window %pR, size %llu, size1 %llu, min_size %llu, add_size %llu, children_add_size %llu\n",
                          b_res,
                          (unsigned long long)size,
                          (unsigned long long)size1,
                          (unsigned long long)min_size,
                          (unsigned long long)add_size,
                          (unsigned long long)children_add_size);

        size0 = calculate_iosize(size, min_size, size1, 0, 0,
                        resource_size(b_res), min_align);
        size1 = (!realloc_head || (realloc_head && !add_size && !children_add_size)) ? size0 :
                calculate_iosize(size, min_size, size1, add_size, children_add_size,
                        resource_size(b_res), min_align);

        /* suppa */ pci_info(bus->self, "(2) for bridge window %pR, size %llu, size1 %llu, min_size %llu, add_size %llu, children_add_size %llu\n",
                          b_res,
                          (unsigned long long)size,
                          (unsigned long long)size1,
                          (unsigned long long)min_size,
                          (unsigned long long)add_size,
                          (unsigned long long)children_add_size);

        /* suppa */ pci_info(bus->self, "bridge window at %pR\n", b_res);
(drivers/pci/setup-bus.c)

Code: [Select]

pci 0000:00:06.0: (1) for bridge window [io  0x0000], size 1536, size1 0, min_size 8192, add_size 8192, children_add_size 0
pci 0000:00:06.0: (2) for bridge window [io  0x0000], size 1536, size1 8192, min_size 8192, add_size 8192, children_add_size 0
pci 0000:00:06.0: bridge window at [io  0x0000]


Code: [Select]

via-rhine 0000:00:02.0: enabling device (0080 -> 0083)
via-rhine 0000:00:02.0 eth1: VIA Rhine III at (ptrval), 00:0c:42:0e:9f:1c, IRQ 142
via-rhine 0000:00:02.0 eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:00:03.0: enabling device (0080 -> 0083)
via-rhine 0000:00:03.0 eth2: VIA Rhine III at (ptrval), 00:0c:42:0e:9f:1d, IRQ 143
via-rhine 0000:00:03.0 eth2: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
pci 0000:00:06.0: enabling device (0000 -> 0003)
via-rhine 0000:01:02.0: enabling device (0080 -> 0083)
via-rhine 0000:01:02.0 eth3: VIA Rhine III at (ptrval), 00:0c:42:03:58:fb, IRQ 141
via-rhine 0000:01:02.0 eth3: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:03.0: enabling device (0080 -> 0083)
via-rhine 0000:01:03.0 eth4: VIA Rhine III at (ptrval), 00:0c:42:03:58:fc, IRQ 143
via-rhine 0000:01:03.0 eth4: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:04.0: enabling device (0080 -> 0083)
via-rhine 0000:01:04.0 eth5: VIA Rhine III at (ptrval), 00:0c:42:03:58:fd, IRQ 140
via-rhine 0000:01:04.0 eth5: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:05.0: enabling device (0080 -> 0083)
via-rhine 0000:01:05.0 eth6: VIA Rhine III at (ptrval), 00:0c:42:03:58:fe, IRQ 142
via-rhine 0000:01:05.0 eth6: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:06.0: enabling device (0080 -> 0083)
via-rhine 0000:01:06.0 eth7: VIA Rhine III at (ptrval), 00:0c:42:03:58:ff, IRQ 141
via-rhine 0000:01:06.0 eth7: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:07.0: enabling device (0080 -> 0083)
via-rhine 0000:01:07.0 eth8: VIA Rhine III at (ptrval), 00:0c:42:03:59:00, IRQ 143
via-rhine 0000:01:07.0 eth8: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000


Code: [Select]

#define DEFAULT_BRIDGE_IO_SIZE          (8192)   /* suppa */
/* pci=bridgeiosize=nn can override this */
(drivers/pci/pci.c)

Code: [Select]

rb532 / # ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1b
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:40

eth1      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1c
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1d
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fb
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth4      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fc
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth5      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fd
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth6      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fe
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth7      Link encap:Ethernet  HWaddr 00:0c:42:03:58:ff
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth8      Link encap:Ethernet  HWaddr 00:0c:42:03:59:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


[DiTBho]

Code: [Select]

[*] networking-bridge
networking-devices[]={  eth0  eth1  eth2  eth3  eth4  eth5  eth6  eth7  eth8  }
korina korina eth0: link up, Mbps, full-dux, lpa 0xFFFFF


Code: [Select]

rb532a ~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1b
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6966 (6.8 KiB)  TX bytes:17094 (16.6 KiB)
          Interrupt:40

eth1      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1c
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr 00:0c:42:0e:9f:1d
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fb
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth4      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fc
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth5      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fd
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth6      Link encap:Ethernet  HWaddr 00:0c:42:03:58:fe
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth7      Link encap:Ethernet  HWaddr 00:0c:42:03:58:ff
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth8      Link encap:Ethernet  HWaddr 00:0c:42:03:59:00
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1039 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1039 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:89196 (87.1 KiB)  TX bytes:89196 (87.1 KiB)

mybridge  Link encap:Ethernet  HWaddr 00:0c:42:03:58:fb
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:322 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5166 (5.0 KiB)  TX bytes:17062 (16.6 KiB)

bridge support, all ethernet { eth0 .. eth8 } connected to mybridge
we'll see if it works!

[Nominal Animal]

Code: [Select]

PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [111d:0000] type 00 class 0x000000
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x07ffffff pref]
pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)


BTW, the above is "normal" for 111d:0000 = PCI_VENDOR_ID_IDT:0000, as it predates even PCI_DEVICE_ID_IDT77201 (=0001); the above just says that second and third BAR on this PCI root behave in a nonstandard way.  It can be silenced with a quirk, but I'm not sure it's worth the effort; there would be no functional changes.

Code: [Select]

pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci 0000:00:06.0: BAR 7: assigned [io  0x18800000-0x18801fff]
pci 0000:00:02.0: BAR 0: assigned [io  0x18802000-0x188020ff]
pci 0000:00:03.0: BAR 0: assigned [io  0x18802400-0x188024ff]
pci 0000:01:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
pci 0000:01:03.0: BAR 0: assigned [io  0x18800400-0x188004ff]
pci 0000:01:04.0: BAR 0: assigned [io  0x18800800-0x188008ff]
pci 0000:01:05.0: BAR 0: assigned [io  0x18800c00-0x18800cff]
pci 0000:01:06.0: BAR 0: assigned [io  0x18801000-0x188010ff]
pci 0000:01:07.0: BAR 0: assigned [io  0x18801400-0x188014ff]


Nice, the I/O window on the bridge (0000:00:06.00) now gets allocated the correct size, and everything is as expected. 

Code: [Select]

pci 0000:00:06.0: (1) for bridge window [io  0x0000], size 1536, size1 0, min_size 8192, add_size 8192, children_add_size 0
pci 0000:00:06.0: (2) for bridge window [io  0x0000], size 1536, size1 8192, min_size 8192, add_size 8192, children_add_size 0


1536?

That size 1536 means that the io aperture size is calculated as if all the devices under the bridge, i.e. 0000:01:02.0 through 0000:01:07.0, can be stuffed into a single window on the bridge: 6×0x100 = 0x600 = 1536.  I do not believe this is true.  I believe each device needs their own I/O window on the bridge, which is what the above (assumed working!) configuration shows.  The correct way to account for the total bridge I/O window aperture size needed, I believe, would be to find out the maximum alignment first, then align and pad the per-device window needed (but multiple I/O ranges for a single device I do believe can be combined).  The bridge I/O window size needed is the sum of those per-device window sizes.

The simple reason is that I don't see how the Linux kernel could give half a window to one device, and half to another; yet it counts the needed space exactly like that: just summing the required I/O device window sizes together.  Either I'm very stupid here (always possible), or this is a really, really old bug.

Aaahhh... This could also explain the horrible hack with ISA/EISA I/O windows: If the total number of I/O addresses needed over the bridge is X, and CONFIG_ISA or CONFIG_EISA is defined, then the address count is fudged into (X&0x000000FF) + (X&0xFFFFFF00)<<2, i.e. "multiply the number of 256 address blocks by 4".
Because Intel bridges (those supporting ISA aliasing) also support 1K I/O window sizes, and the ISA aliasing is typically for 256 addresses per device (as that is the maximum allowed for a non-bridge device), this ends up doing the above alignment in practice – but only when ISA or EISA is enabled!
I think the root cause could be a silly "multiply by four" thinko in some early PCI documentation, where the need for reserving entire windows even though only part of each window ends up being used, was confused by Intel using 1k I/O windows instead of 4k ones, somehow leading to the magic multiply-by-four.

I could be wrong, though.  I'm not that familiar with the Linux PCI subsystem, and you know me: me fail every now and then.

I can generate an RFC patch to submit upstream (LKML) for discussion, but I don't have any x86/x86-64 hardware with non-root PCI bridges to test and verify it myself (that it does the right thing even on x86/x86-64 hardware with ISA devices under a non-root PCI bridge).  Non-PCIe hardware would be best.. Hey, do you happen to know people with older x86 hardware, that might be willing to test a kernel patch, comparing the PCI logs between the patched and unpatched kernels?  To get traction at LKML, one has to post under their own name after submitting a Developer Certificat of Origin, and I'm not sure I'm ready to give up my safety-blankie of a pseudonym yet.   

[DiTBho]

I could be wrong, though.  I'm not that familiar with the Linux PCI subsystem, and you know me: me fail every now and then.

me neither, the PCI on Linux is something very "vague" for me 

soon I will have to write a low-level driver for mymon/mips
which will also be ported to a PowerPC 40x
that because it is the only non-x86 card with PCI and a PCI-CF interface that runs at 5V

I will definitely write something to handle PCI directly.
I will not follow the Linux kernel code, everything will be written from scratch.

I can generate an RFC patch to submit upstream (LKML) for discussion,
but I don't have any x86/x86-64 hardware with non-root PCI bridges to test and verify it myself

I don't know, I definitely have a feeling there are other problems with the Cryptoprocessor and quad-serials miniPCI devices

I would like to have on the rb532a
They can reveal other bugs and defects with the PCI

What to do? Where to discuss? 

[Nominal Animal]

Oopsie!  The windowing argument isn't generally true.  On MIPS, it's caused by arch/mips/pci/pci-legacy.c:pcibios_align_resource() or arch/mips/pci/pci-generic.c:pcibios_align_resource().

Essentially, on alpha, arm (32-bit), m68k, mips pci-generic and pci-legacy, powerpc, sh, i386 and xtensa apply I/O address space adjustments not accounted for in the allocation, because some "external [ISA] I/O cards only decode the low 10 bits of the address".  This is what applies the 1k window per device.

First of all, this makes absolutely no sense when CONFIG_ISA=n, CONFIG_EISA=n.  If your CONFIG_PCI_DRIVERS_LEGACY=y, could you check if modifying linux-6.0.2/arch/mips/pci/pci-legacy.c:pcibios_align_resource() into

Code: [Select]

resource_size_t
pcibios_align_resource(void *data, const struct resource *res,
       resource_size_t size, resource_size_t align)
{
struct pci_dev *dev = data;
struct pci_controller *hose = dev->sysdata;
resource_size_t start = res->start;

if (res->flags & IORESOURCE_IO) {
/* Make sure we start at our min on all hoses */
if (start < PCIBIOS_MIN_IO + hose->io_resource->start)
start = PCIBIOS_MIN_IO + hose->io_resource->start;

#if defined(CONFIG_ISA) || defined(CONFIG_EISA)
/*
* Put everything into 0x00-0xff region modulo 0x400
*/
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
#endif
} else if (res->flags & IORESOURCE_MEM) {
/* Make sure we start at our min on all hoses */
if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start)
start = PCIBIOS_MIN_MEM + hose->mem_resource->start;
}

return start;
}or, if CONFIG_PCI_DRIVERS_GENERIC=y, linux-6.0.2/arch/mips/pci/pci-generic.c:pcibios_align_resource() into

Code: [Select]

resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
{
struct pci_dev *dev = data;
resource_size_t start = res->start;
struct pci_host_bridge *host_bridge;

#if defined(CONFIG_ISA) || defined(CONFIG_EISA)
if (res->flags & IORESOURCE_IO && start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
#endif

start = (start + align - 1) & ~(align - 1);

host_bridge = pci_find_host_bridge(dev->bus);

if (host_bridge->align_resource)
return host_bridge->align_resource(dev, res,
start, size, align);

return start;
}
without any other changes I've suggested, fixes the issue?  It should, assuming you have CONFIG_ISA=n (or undefined) and CONFIG_EISA=n (or undefined).

It should work, and cause the io windows to be packed consecutively within the 0x0000-0x05ff range for the 0000:01:02.0-0000:01:07.0 devices.

[DiTBho]

Code: [Select]

0 drivers/pci/setup-bus.c reverted to original
~ arch/mips/pci/pci-legacy.c modified


Code: [Select]

# rb532a does not compile
#        with
#             PCI_DRIVERS_GENERIC
#        needs
#             PCI_DRIVERS_LEGACY
config MIKROTIK_RB532
        bool "Mikrotik RB532 boards"
        select CEVT_R4K
        select CSRC_R4K
        select DMA_NONCOHERENT
        select HAVE_PCI
        select IRQ_MIPS_CPU
        select SYS_HAS_CPU_MIPS32_R1
        select SYS_SUPPORTS_32BIT_KERNEL
        select SYS_SUPPORTS_LITTLE_ENDIAN
        select SWAP_IO_SPACE
        select BOOT_RAW
        select GPIOLIB
        select MIPS_L1_CACHE_SHIFT_4
        help
          Support the Mikrotik(tm) RouterBoard 532 series,
          based on the IDT RC32434 SoC.
(arch/mips/Kconfig, my notes)

Code: [Select]

PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [111d:0000] type 00 class 0x000000
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x07ffffff pref]
pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:02.0: [1106:3106] type 00 class 0x020000
pci 0000:00:02.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:00:02.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:00:03.0: [1106:3106] type 00 class 0x020000
pci 0000:00:03.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:00:03.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:00:03.0: supports D1 D2
pci 0000:00:03.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:00:04.0: [13a3:0020] type 00 class 0x0b4000
pci 0000:00:04.0: reg 0x10: [mem 0x00000000-0x00000fff]
pci 0000:00:04.0: reg 0x14: [mem 0x00000000-0x00001fff]
pci 0000:00:04.0: reg 0x18: [mem 0x00000000-0x00007fff]
pci 0000:00:06.0: [3388:0031] type 01 class 0x060400
pci 0000:00:06.0: supports D1 D2
pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci_bus 0000:01: extended config space not accessible
pci 0000:01:02.0: [1106:3106] type 00 class 0x020000
pci 0000:01:02.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:02.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:02.0: supports D1 D2
pci 0000:01:02.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:03.0: [1106:3106] type 00 class 0x020000
pci 0000:01:03.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:03.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:03.0: supports D1 D2
pci 0000:01:03.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:04.0: [1106:3106] type 00 class 0x020000
pci 0000:01:04.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:04.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:04.0: supports D1 D2
pci 0000:01:04.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:05.0: [1106:3106] type 00 class 0x020000
pci 0000:01:05.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:05.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:05.0: supports D1 D2
pci 0000:01:05.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:06.0: [1106:3106] type 00 class 0x020000
pci 0000:01:06.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:06.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:06.0: supports D1 D2
pci 0000:01:06.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:01:07.0: [1106:3106] type 00 class 0x020000
pci 0000:01:07.0: reg 0x10: [io  0x0000-0x00ff]
pci 0000:01:07.0: reg 0x14: [mem 0x00000000-0x000000ff]
pci 0000:01:07.0: supports D1 D2
pci 0000:01:07.0: PME# supported from D1 D2 D3hot D3cold
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
pci 0000:00:06.0: BAR 8: assigned [mem 0x50000000-0x500fffff]
pci 0000:00:04.0: BAR 2: assigned [mem 0x50100000-0x50107fff]
pci 0000:00:04.0: BAR 1: assigned [mem 0x50108000-0x50109fff]
pci 0000:00:04.0: BAR 0: assigned [mem 0x5010a000-0x5010afff]
pci 0000:00:06.0: BAR 7: assigned [io  0x18800000-0x18800fff]
pci 0000:00:02.0: BAR 0: assigned [io  0x18801000-0x188010ff]
pci 0000:00:02.0: BAR 1: assigned [mem 0x5010b000-0x5010b0ff]
pci 0000:00:03.0: BAR 0: assigned [io  0x18801100-0x188011ff]
pci 0000:00:03.0: BAR 1: assigned [mem 0x5010b100-0x5010b1ff]
pci 0000:01:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
pci 0000:01:02.0: BAR 1: assigned [mem 0x50000000-0x500000ff]
pci 0000:01:03.0: BAR 0: assigned [io  0x18800100-0x188001ff]
pci 0000:01:03.0: BAR 1: assigned [mem 0x50000100-0x500001ff]
pci 0000:01:04.0: BAR 0: assigned [io  0x18800200-0x188002ff]
pci 0000:01:04.0: BAR 1: assigned [mem 0x50000200-0x500002ff]
pci 0000:01:05.0: BAR 0: assigned [io  0x18800300-0x188003ff]
pci 0000:01:05.0: BAR 1: assigned [mem 0x50000300-0x500003ff]
pci 0000:01:06.0: BAR 0: assigned [io  0x18800400-0x188004ff]
pci 0000:01:06.0: BAR 1: assigned [mem 0x50000400-0x500004ff]
pci 0000:01:07.0: BAR 0: assigned [io  0x18800500-0x188005ff]
pci 0000:01:07.0: BAR 1: assigned [mem 0x50000500-0x500005ff]
pci 0000:00:06.0: PCI bridge to [bus 01]
pci 0000:00:06.0:   bridge window [io  0x18800000-0x18800fff]
pci 0000:00:06.0:   bridge window [mem 0x50000000-0x500fffff]


Code: [Select]

via-rhine 0000:00:02.0: enabling device (0080 -> 0083)
via-rhine 0000:00:02.0 eth1: VIA Rhine III at (ptrval), 00:0c:42:0e:9f:1c, IRQ 142
via-rhine 0000:00:02.0 eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:00:03.0: enabling device (0080 -> 0083)
via-rhine 0000:00:03.0 eth2: VIA Rhine III at (ptrval), 00:0c:42:0e:9f:1d, IRQ 143
via-rhine 0000:00:03.0 eth2: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
pci 0000:00:06.0: enabling device (0000 -> 0003)
via-rhine 0000:01:02.0: enabling device (0080 -> 0083)
via-rhine 0000:01:02.0 eth3: VIA Rhine III at (ptrval), 00:0c:42:03:58:fb, IRQ 141
via-rhine 0000:01:02.0 eth3: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:03.0: enabling device (0080 -> 0083)
via-rhine 0000:01:03.0 eth4: VIA Rhine III at (ptrval), 00:0c:42:03:58:fc, IRQ 143
via-rhine 0000:01:03.0 eth4: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:04.0: enabling device (0080 -> 0083)
via-rhine 0000:01:04.0 eth5: VIA Rhine III at (ptrval), 00:0c:42:03:58:fd, IRQ 140
via-rhine 0000:01:04.0 eth5: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:05.0: enabling device (0080 -> 0083)
via-rhine 0000:01:05.0 eth6: VIA Rhine III at (ptrval), 00:0c:42:03:58:fe, IRQ 142
via-rhine 0000:01:05.0 eth6: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:06.0: enabling device (0080 -> 0083)
via-rhine 0000:01:06.0 eth7: VIA Rhine III at (ptrval), 00:0c:42:03:58:ff, IRQ 141
via-rhine 0000:01:06.0 eth7: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000
via-rhine 0000:01:07.0: enabling device (0080 -> 0083)
via-rhine 0000:01:07.0 eth8: VIA Rhine III at (ptrval), 00:0c:42:03:59:00, IRQ 143
via-rhine 0000:01:07.0 eth8: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000


Code: [Select]

not CONFIG_ISA
not CONFIG_EISA
(profile/config_check.list) -> my constructor checks if each entry in config_check.list is "set" or "not set" in the .config file
When an item is preceded by "not", it means the builder checks the item not be set

[Nominal Animal]

Nice! 

The correct upstream fix is those two #if defined(CONFIG_ISA) || defined(CONFIG_EISA) ... #endif guards in the mips pci-generic/pci-legacy.

Un-fucking believable: this idiotic bug –– nobody noticing the negative effects of an ISA workaround on an architecture with no ISA –– had stopped RB564 from basically ever fully working under Linux/OpenWRT.  Well, there might be some version or patch where that "ISA workaround" is patched out or disabled on mips, but I haven't found one yet.  I mean, the bug is there in 2.6.8 (arch/mips/pci/pci.c+drivers/pci/setup-bus.c) from 2004, through 2.6.20 (arch/mips/pci/pci.c+drivers/pci/setup-bus.c) through 2.6.39 (arch/mips/pci/pci.c+drivers/pci/setup-bus.c), through 6.13.2 (arch/mips/pci/pci-generic.c+arch/mips/pci/pci-legacy.c+drivers/pci/setup-bus.c), basically unchanged.  Just an obvious preprocessor guard missing per file, all this time.  This bug is over two decades old now.

If you think it okay, I could create a properly formatted patch, and send it to you via email for your comparison/testing, and we could see about upstreaming the fix, at least for MIPS.  As I listed above, other arches (including 32-bit ARM) suffers from the same bug, so some notifications are in order.  In particular, your Tested-By: would be invaluable for traction... plus I'm pretty sure OpenWRT and others would be interested in this fix; they run exactly the kind of motley hardware that is susceptible to this bug.

[DiTBho]

Umm, it looks like no one has responded to the patch yet 

In the meantime, I bought a mini lot of 5 boards, one for each person in my friend group.
As for mymon development, the pATA driver is stable enough to load stuff from the microdrive,
so I'm working on PCI driver using the linux kernel source as reference
as I am not able to find any development SDK (other examples?) for the IDT SoC.

[DiTBho]

Code: [Select]

# help pci.*
pci.scan............       brute force, checking every device on every PCI bus 
pci.regsdump........       dump pci registers

I implemented wildchars as library, it's used for both "hex-pattern-searching" and the help to list all the commands that belong to the same class.

Code: [Select]

# pci.scan
0:0 magic=0x0000111d
0:2 magic=0x31061106
0:3 magic=0x31061106


Code: [Select]

boolean_t pci_scan
(
    p_pci_t p_pci
)
{
    boolean_t ans;
    boolean_t is_ok0;
    boolean_t is_ok1;

    uint32_t  dev_num;
    uint32_t  fun_num;
    uint32_t  reg_num;
    uint32_t  magic;

    is_ok0 = p_pci->is_ok;
    if (is_ok0 isEqualTo True)
    {
        fun_num = 0; /* dc, for now */
        reg_num = 0; /* dc, for now */

        for (bus_num = 0; bus_num < 256; bus_num++)
        {
            for (dev_num = 0; dev_num < 32; dev_num++)
            {
                magic = pci_config_read(p_pci, bus_num, dev_num, fun_num, reg_num);
                is_ok1 = (magic isNotEqualTo 0xffffffff);
                if (is_ok isEqualTo True)
                {
                    print_uint32(bus_num, "", ":");
                    print_uint32(dev_num, "", " ");
                    print_hex32(magic, "magic=0x", "\n");
                }
            }
        }
    }
    ans = is_ok0;
    return ans;
}

It took two days, because the Mikrotik firmware leaves the rc32434 pci in a... emm "undefined state".
So, the PCI registers have to be reconfigured before you can read the config space, otherwise mymon crashes.

It starts moving 

[Nominal Animal]

I implemented wildchars as library, it's used for both "hex-pattern-searching" and the help to list all the commands that belong to the same class.

Similar to, or a subset of fnmatch(), also known as POSIX globbing?

I've only ever really needed ? (any single character), * (anything, zero or more characters), and ranges (like [0-9A-Za-z]) where each range acts like a limited ?, only "occupying" one character in the string.  Implementation approaches are well known, and much, much simpler than e.g. regular expressions that really require a full state machine.  (One often used approach is linear, but splitting the pattern at *'s and optimizing the sub-pattern search, essentially skipping any * parts.  Very robust –– easy to avoid buffer overruns ––, and usually performance is more than acceptable, even if it is not the most performant approach.)

It took two days, because the Mikrotik firmware leaves the rc32434 pci in a... emm "undefined state".

Eww.  But not really surprising!

[DiTBho]

I implemented wildchars as library, it's used for both "hex-pattern-searching" and the help to list all the commands that belong to the same class.

Similar to, or a subset of fnmatch(), also known as POSIX globbing?

I've only ever really needed ? (any single character), * (anything, zero or more characters), and ranges (like [0-9A-Za-z]) where each range acts like a limited ?, only "occupying" one character in the string.  Implementation approaches are well known, and much, much simpler than e.g. regular expressions that really require a full state machine.  (One often used approach is linear, but splitting the pattern at *'s and optimizing the sub-pattern search, essentially skipping any * parts.  Very robust –– easy to avoid buffer overruns ––, and usually performance is more than acceptable, even if it is not the most performant approach.)

Umm, I think it's similar to globbing 

[DiTBho]

It took two days, because the Mikrotik firmware leaves the rc32434 pci in a... emm "undefined state".

Eww.  But not really surprising!

bah, I got surprised, probably due to the specs I have for the things I do at work:
"when you write a bootloader, never leave a bus in an undefined state before loading and booting the application"
(my boss)

I think she is right - "because" - she added - "it is typical to assume that the buses have already been initialized,
there are kernels like WxWorks that do not bother to do any initialization at all."

She made a gesture with her hand, - "It costs you little, but for those who come after you" -
like the teachers at school who want to lecture you -"it could save them days or weeks of work."

Ummm, and do you remember that bloody 40xPPC board I talked you about? u-boot had the same issue.
And it took us several months before we understood why?!? the linux kernel had strange malfunctions with the sata HBA.

The reason is that often in SoCs that integrate PCI, the various registers start in an undefined state,
most likely because they are not reset by the physical reset signal.

Some registers must be set by hand, you can't trust their default value, even if the manual doesn't explicitly say so.
It's never a good idea to keep them as they are from a reset.
Worse still, if the firmware doesn't do any initialization, believing that the kernel should do it,
and the kernel then doesn't do it, because it believes that the firmware should do it ...

In the end ... nobody does it and things don't work as they should.

-

In the case of the rb532, it is expected that at least the mac-address of the VIA-chip added by the rb564 expansion card should be listed
I guess, to do this, it is necessary to go through the PCI, so the fw should initialize it, and then deactivate it before bootstrapping the application

What I observe from the dump of the PCI registers is instead an indefinite mess ...
... where the only right thing is a bit that activates the PCI, but all the other values ​​are wrong/undefined.

Why they do it this way? It's an x-file ... 

[Nominal Animal]

"when you write a bootloader, never leave a bus in an undefined state before loading and booting the application"
"because" - she added - "it is typical to assume that the buses have already been initialized,
there are kernels like WxWorks that do not bother to do any initialization at all."
"It costs you little, but for those who come after you"
"it could save them days or weeks of work."

I like her!

Why they do it this way?

When the same company does both hardware and bootloader and OS, and there is pressure to keep development costs down, such things inevitably happen.  The hardware folks cut costs by shifting things like reset state to the software folks.  Bootloader folks cut costs by limiting their responsibilities to the minimum that suffices for booting the device.  The OS devs get stuck with the mess, so they minimize their own work by taking some older version of Linux and hacking that sufficiently to get stuff working.

It's a messy situation that produces less than desirable results, but as long as it is saleable and the clients don't complain overmuch, Mikrotik doesn't care.  I call it bad leadership and business management –– but then again, I'm never about the short-term bottom line, but always about the long term results.  Most investors and shareholders and therefore company executives are satisfied with the short term profit.  Thus, I did not find this at all surprising.

[DiTBho]

see, in the end, I ended up writing a full SDK for the rb532a.

Yesterday one of the guys in my group of friends bought an rb564 (so now we have two), and in the same order I also received a "rb532 board" practically for free (+5 euros).
It is the older version of the r532a.
It has half the clock of the rb532a CPU and half the RAM, it also has no buzzer and has a slightly different routing for some GPIOs.

Interesting and very useful for testing

It is far from where I am, but it connected to one of my friend's development miniPCs;
so, over ssh, I can access the serial, do a hw reset and boot a custom elf image.

Code: [Select]

device="/dev/ttyS1"
stty -F $device cs8 -parenb cstopb crtscts
screen -R term $device 9600
(on the remote computer)

[DiTBho]

only one 5 hours (during WE) to add the Watchdog

Code: [Select]

# wdt regs
0xb8030030: 0x00000007 status  Watchdog timer status  0b111
0xb8030034: 0x00000000 count   Watchdog timer count   0b0
0xb8030038: 0x00000000 compare Watchdog timer compare 0b0
0xb803003c: 0x00000000 ctrl    Watchdog timer control 0b0


Code: [Select]

# wdt.timeout=5
# wdt.en=1
# wdt.count
5
# wdt.count
2
#
RouterBOOT booter 2.12

RouterBoard 532a

CPU frequency: 400 MHz
  Memory size:  64 MB

I can add wdt.start to the shell module.
So when it invokes a command of something exprimental that goes nut and doesn't return as it should
the wdt will isse a physical hw-reset to reset the board.

Attached to the rb532a power-in line, I have a circuit  that a hw reset to the routherboard.
It uses a relay to temporaly (2sec) cut the 12V power.  It uses the rs232 RTS signal as control.
It works, wut with the wdt it is simply better and I will not lose the things saved in the dram.