armada370 serial port that can send but not receive

I'm working with a device (Buffalo Terastation TS1400D) that uses one of the SoC uart connections (uart1) to communicate with an on-board microcontroller which control some of the devices peripherals (fan speed, leds, buzzer etc). I'm able to send commands to it (and can see/hear that it's executing the) but I am not getting any of the acknowledgement messages back. When doing the same thing under the stock firmware everything works as expected in both directions.

I've got the same thing working perfectly on a very similar device (Buffalo Terastation TS3400D). Them main differences between them are that the 3400 is an armadaxp device and it uses uart3 rather than uart1 for this connection.

Has anyone run into a similar situation where they could only send data one-way like this?

> Has anyone run into a similar situation where they
> could only send data one-way like this?

I have seen it, but only when one of these scenarios is true:

- The serial console command has a different settings (baud rate,...) that the box is expecting.
- u-boot envs for stdin/stdout/stderr were set to wrong values.

If stock FW works for both directions, then you should at least get the u-boot booting output, and able to interrupt u-boot, executing commands and see their output ... when running different rootfs (the kernel on it does not get involved until u-boot loaded and start booting the kernel).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

in this case the console/etc are all on uart0, as far as I've been able to tell uart1 doesn't have anything like that assigned. as far as i can tell.

Even if it was I would still find this odd, at least if it were stdout/stderr since those are all "output" and output is what is succeeding for me.

I've been half wondering if something else could be grabbing the rx gpio for that port but as far as i can tell nothing should be and I would expect other errors to occur in that case.

> Even if it was I would still find this odd, at
> least if it were stdout/stderr since those are all
> "output" and output is what is succeeding for me.

I am a little bit unclear. I though you can execute commands but did not get any output back?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'm not explaining it well.

I'm sending commands from the device to an external microcontroller via uart1 (it's on the pcb but is external from the os's perspective). if stdout was going out uart1 that output would also go "out" to the microcontroller.

i can tell the commands I send out are being received and accepted because the microcontroller plays the expected sounds and enables the expected leds etc. I should be getti back responses too. every command should get either an acknoledgment or an error but I am not seeing anything on the port come back.

I've started to document the protcol in question of that helps:
https://buffalonas.miraheze.org/wiki/Terastation_Microcontroller_Interface

That uart1 pins are mpp41, mmp42 and I too did not see anything in your DTS that grabs the pin.

What are bout IRQ? uart1 IRQ is 42.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

hmm, good thought.

so, this is what I'm seeing:

root@ts1400d-stretch:~# dmesg | grep serial
[    1.231269] d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 19, base_baud = 12500000) is a 16550A
[    2.039621] d0012100.serial: ttyS1 at MMIO 0xd0012100 (irq = 20, base_baud = 12500000) is a 16550A

root@ts1400d-stretch:~# find /proc/irq | grep serial
/proc/irq/19/serial

interestingly they do show as 41 and 42 under the stock firmware.

Ah! stock is always correct, of course. And the DTSI is using that.

armada-370-xp.dtsi

uart0: serial@12000 {
                                compatible = "snps,dw-apb-uart";
                                reg = <0x12000 0x100>;
                                reg-shift = <2>;
                                interrupts = <41>;
                                reg-io-width = <1>;
                                clocks = <&coreclk 0>;
                                status = "disabled";
                        };

                        uart1: serial@12100 {
                                compatible = "snps,dw-apb-uart";
                                reg = <0x12100 0x100>;
                                reg-shift = <2>;
                                interrupts = <42>;
                                reg-io-width = <1>;
                                clocks = <&coreclk 0>;
                                status = "disabled";
                        };

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

interesting, and confusing.

All I'm doing in the dts is enabling them:

serial@12000
{
        status = "okay";
};

serial@12100
{
	status = "okay";
};

Perhaps there is generic IRQ mapping going on here, so

[    1.231269] d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 19, base_baud = 12500000) is a 16550A
[    2.039621] d0012100.serial: ttyS1 at MMIO 0xd0012100 (irq = 20, base_baud = 12500000) is a 16550A

are actually 41 and 42.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yeah, I think so.

Looking at the ts3400 its showing the same thing (but that one works as expected)

I finally got back to looking at this and figured out what the problem is, The default UART1 pins for the armada-370 are 41(RX) and 42(TX), it turns out this device is using 57(RX) and 42(TX), I'll be posting updated device trees that reflect that shortly.

I had previously suspected it was something like that but wasn't detecting activity on the other pins at the time. I guess the script I use to detect things like button presses on unassigned pins doesn't work for 38400 baud serial data. This should make a good test case for a better detection script someday.

@bohdi, thanks again for your help.