I’m not yet in a place to do that, and my systems seem to be stable without the IRQ separation (after I lowered the baud rate on ttyS1 to 38400 from 115200), so I’m happy to wait for a future firmware update. Thanks for the quick response!
Well, it turns out they are not as stable as I thought; in a few days, I’ll have one or two episodes of data being dropped, and then the application having to re-sync with the device. I’ll look into the custom DTB thing to see what I can do.
My attempt to change the IRQ failed; not sure if the patch didn’t get applied properly, or something else happened, but after a reboot the IRQ had not changed. I’ve reverted to the unpatched kernel now.
Yes, it’s GPS NMEA data, being fed into gpsd; no flow control, 38,400 baud. It was worse at 115,200 baud, so I’m nearly certain that data is occasionally being dropped.
21c0600.serial: ttyS1 at MMIO 0x21c0600 (irq = 17, base_baud = 10937500) is a 16550A_FSL64
It passes a loopback test for me, will need to rig up a GPS receiver to do a NMEA test.
Another option available is to configure the UARTs (via RCW) as 4 x 2-wire instead of 2 x 4-wire.
This would give you a RX and TX pair where the CTS and RTS pins are.
These would be on duart2 which has it’s own IRQ.
Well… I suppose this is a local issue, but even though I patched the DTB source and built a new kernel package (and I can see that the resulting DTB file is smaller than it was before, which makes sense as there were two ‘compatible’ entries previously), after a reboot that new DTB has not been used and the UARTs are still seen as regular 16550s.
I’m not really sure where the Debian kernel loads DTBs from, there are a lot of moving parts here (U-boot, systemd-boot, etc.). I’ll continue to investigate.
Where are you putting the DTB? Somewhere under /boot?
The U-Boot in firmware v0.8.x is configured to only load the DTB from the devicetree partition on the flash.
The reason is to avoid issues that occur when a different DTB is substituted.
(There is the IOMMU fixup issue and also preventing older, incomplete versions of the DTB being loaded)
The new U-Boot in v0.9.x should support loading a DTB from the EFI/boot partition, but I need to check from where exactly.
So in summary:
Use the recovery firmware to write a new DTB to flash (mtd erase devicetree && mtd write mydtb.dtb devicetree)
Or change the U-Boot setup_distroboot_efi command to load the DTB from somewhere else
For your purposes, device tree overlay support will make this much easier, but there is just a bit more work to do before that can be enabled.
That process worked, the system has booted with the revised DTB and the kernel messages show that the UARTs are in 64-byte FIFO mode. I’ll monitor the GPS receiver process over the next week or two to see if the situation has improved.
Well, no problems caused by this change (this is good).
Weirdly, the other box, which has not had the new DTB applied, has also not had any NMEA data disruption during the same time, so there may have been other changes (new kernel, etc.) which improved the situation.
However, ‘chronyc sourcestats’ shows that the GPS source is more stable (lower standard deviation of offset) on the one with the 64-byte FIFOs enabled, so I’ll apply that DTB to my second box too.
Is it worth sending a patch upstream to change the default in the kernel?
The second box, without the updated DTB, had two NMEA data ‘blips’ overnight, and the one with the updated DTB did not. I’ll get the DTB applied to that box today and within a week or so I should be able to report whether the problem appears to have been resolved.