[Aedan Cullen]

According to previous info from Octavo, the OSD32MP157C uses the same DRAM device as the STM32MP157C-DK2 and STM32MP157F-DK2: Micron MT41K256M16TW-107:P. The clock is indeed 533MHz, and the interface is x16. Both the DK2 boards and Octavo’s board support appear to use 8-8-8 timings (CL=8), which puts the absolute CAS latency at 15 ns. Since the SiP should maintain this same DDR choice as the DK2, I wouldn’t expect to see huge memory performance differences.

DK2 configuration https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi

OSD32MP1 configuration: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/u-boot-v2020.10-r0/stm32mp15-osd32mp1-ddr3-1x4Gb.dtsi

You’ll notice the two are identical with the exception of some PHY tuning parameters near the end. For more information on the details, see ST AN5168.

 

[Aedan Cullen]

I haven’t yet gathered a complete understanding of this, but an initial search suggests that you’d want to check the reset and such: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/692995/linux-am3358-ethernet-phy-error 

Reset seems even more of a potential culprit given your device tree – could you explain the comment about the TCA6424 on your board coming up later? You could probe the reset signal to take a look at it relative to other signals to the PHY, and first maybe see if you can rule out reset as the cause of the issue.

[Aedan Cullen]

Here’s the next thing I’d try:

 

In your device tree node for SPI6, set the dmas property as follows:

 

dmas = <&mdma1 34 0x0 0x40008 0x0 0x0 0x0>,

<&mdma1 35 0x0 0x10040002 0x0 0x0 0x0>;

 

Compared to stm32mp151.dtsi, which has 0x40002 as the third parameter in the TX DMA, the value 0x10040002 should enable block transfer mode. If this doesn’t work (we might need to tweak more things for the block transfer to complete successfully), send the error/register dump from dmesg again. (Unfortunately I don’t have a similar SPI display laying around to actually test on.)

 

 

 

Full thought process, starting with what I think caused the overruns with your original SPI5 configuration:

 

– DCMI is always going to be using one of the standard DMA controllers, DMA1 or DMA2 (selected by the DMAMUX) [1].

– SPI5 will also be automatically assigned a stream by the DMAMUX driver in the same way [2]. Most likely, all eight streams of DMA1 are not yet occupied, and so both DCMI and SPI5 end up on the same DMA1 controller.

– DMA1/DMA2 only arbitrate between streams once a request is completely finished [3]. That is, DMA1 will wait until your 26Kbyte display frame is completed before possibly servicing the DCMI, even if the DCMI stream has a higher priority.

– Probably, the display frame transfer takes long enough over SPI5 that a DCMI frame is guaranteed to start before the display frame transfer is completed. Check whether this is true with whatever framerate you use for your image sensor.

– So then the DCMI FIFO is guaranteed to overflow anytime you transfer a display frame, regardless of priority.

 

So we either need SPI display frame transfers to be much faster, or we need to use a separate DMA controller. Incidentally, your SPI6 configuration achieves exactly that and uses MDMA instead [1]. (The separate DMA controller is what we need, not proximity to the ARM cores [4].)

 

MDMA breaks because TRGM[1:0] is left as 00 in CTCR (as if to configure a buffer transfer) but the data length is set in CBNDTR (for a block transfer). The TLEN (for buffer length) is left as the default one byte, which can’t be packed into a 16-bit write to the peripheral, so you get the BSE error. The MDMA driver seems to deal with the data length registers properly (you must use a block transfer above 128 bytes), but it doesn’t automatically switch to a block transfer in CTCR. In the device tree property above, I’m setting TRGM[1:0] in CTCR to 01 instead of 00. More debugging might be required after this, but you definitely need the MDMA to be in block transfer mode.

 

[1] per stm32mp151.dtsi.

[2] line 110 of stm32-dmamux.c.

[3] section 2.2.3 of ST AN4031. F7, H7, and MP1 use the same DMA IP as far as I know.

[4] The A7 cores are not involved during DMA transfers between memory and a peripheral.

 

Octavo, is there some sort of allow-list that the forum has for trusted users so that I could post links without being caught by the spam filter? 🙂

• This reply was modified 1 year, 4 months ago by Aedan Cullen. Reason: fixed missing zero in hex

[Aedan Cullen]

Do you have readouts of those MDMA registers from a successful 25600-byte transfer on SPI5?

[Aedan Cullen]

Information about latency:

The DRAM device used on the STM32MP157C-DK2 and STM32MP157F-DK2 boards is Micron MT41K256M16TW-107:P. This is an 1866MT/s-grade device being run at 1066 speed. With the provided configurations, both the DK2 boards and Octavo’s boards use conservative 8-8-8 (CL=8) timings at 533MHz, which produces an absolute CAS latency of 15 ns.

(If you diff the DDR configuration file for the DK2 boards against Octavo’s configuration, you can see that the only differences are some PHY tuning parameters. ST AN5168 has more details on how this works if you’re interested.)

Considering this, I wouldn’t expect to see huge memory performance differences, so it could be quite interesting to find the root cause of your performance issue if you suspected it to be memory-related. Were you seeing worse or better performance on the 650MHz OSD32MP1?

[Aedan Cullen]

This may be due to U-Boot thinking that a key is pressed and interrupting the boot process. If the RX signal is floating, garbage data may be received. Try shorting the RX pin of the BRK’s UART to 3.3V and see if that allows the board to boot.

The current device tree in Octavo’s “MinimalConfig” zip on the CubeMX tutorial page seems not to enable the internal pull-up for RX (check if you see bias-disable near line 189 of stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx.dts.) To fix this, enable the pull-up by using bias-pull-up instead as in this other BRK device tree on GitHub.

[Aedan Cullen]

Because of the unusual “daisy-chain” configuration, we will need the first BRK in the chain (“BRK A”) to route packets through itself to the other device. A bridge interface is probably the best way to accomplish this. (Without a bridge, packets received at the first interface on BRK A will hit a dead end since this routing to BRK B will not happen automatically.) Linux treats a bridge as a network switch with other interfaces attached, and there will be simply a single IP address assigned to the bridge, which should serve as the address for packets to that particular BRK board. There are many guides on interface bridging online, but the general idea is this:

ip link add name br0 type bridge

ip link set dev br0 up

Then make sure both your “upstream” interface (which I’ll call eth0 here) and your “downstream” interface (which I’ll call eth1) are up and running (e.g. you can see RUNNING in ifconfig). Then add both to the bridge:

ip link set eth0 master br0

ip link set eth1 master br0

Then assign the bridge an IP address so that it will receive packets destined for BRK A itself:

ip address add dev br0 192.168.7.1/24

This should allow packets not for 192.168.7.1 to be routed to the other RNDIS interface and to BRK B. The IP address configuration of BRK B will matter too. For resolving issues it would be helpful if you post your ifconfig output on BRK A to provide a better picture of what the situation looks like.

Note: though theoretically this USB “daisy chain” idea could indeed be used with many devices, I would caution against using it where reliability is important or a consistent low-latency interconnect is needed. In some environments prone to unanticipated ESD events and excessive EMI from motors (such as robotics competitions), systems based on many individual USB 2.0 connections have proved extremely troublesome in the past and have been replaced with RS-485.

[Aedan Cullen]

There are two problems here. First, we need to have enumeration on the bus before worrying about RNDIS, but we are not finishing enumeration. (The a_alt_hnp_support failed: -32 error comes from usb_enumerate_device_otg in drivers/usb/core/hub.c.) Lack of RNDIS host support on BRK A may be a problem, but it is a separate problem to worry about after we make it through enumeration.

Investigating that error, I believe the dwc2 driver may have incorrect HNP/SRP attributes in its OTG descriptor when used as a gadget device in kernel 5.10 (that’s the condensed summary of the mess.)

First, verify that you don’t see BRK B in lsusb from BRK A, even though it is connected. This confirms that the enumeration problem exists.

Now, try disabling OTG on the microUSB connector of BRK B by setting its role to a peripheral. The original 5.10 devicetree from Octavo contains this:

&usbotg_hs{

u-boot,dm-pre-reloc;

status = "okay";

phys = <&usbphyc_port1 0>;

phy-names = "usb2-phy";

};

Try changing it as follows and rebuilding the kernel:

&usbotg_hs{

u-boot,dm-pre-reloc;

status = "okay";

phys = <&usbphyc_port1 0>;

phy-names = "usb2-phy";

dr_mode = "peripheral";

};

The above is successful if you no longer see the a_alt_hnp_support error. Unfortunately I’m away from my drawer of Octavo hardware until next semester starts so I can’t test this and it’s very much a shot in the dark. If this does eliminate that error and get BRK B to appear in lsusb, then I will post a full explanation of what was happening and we can proceed to worrying about rndis_host.

If that doesn’t get you anywhere, you could also try adding usb-role-switch; and role-switch-default-mode = "peripheral"; to that same devicetree node.

[Aedan Cullen]

There are two problems here. First, we need to have enumeration on the bus before worrying about RNDIS, but we are not finishing enumeration. (The a_alt_hnp_support failed: -32 error comes from usb_enumerate_device_otg in drivers/usb/core/hub.c.) Lack of RNDIS host support on BRK A may be a problem, but it is a separate problem to worry about after we make it through enumeration.

Investigating that error, I believe the dwc2 driver may have incorrect HNP/SRP attributes in its OTG descriptor when used as a gadget device in kernel 5.10 (that’s the condensed summary of the mess.)

First, verify that you don’t see BRK B in lsusb from BRK A, even though it is connected. This confirms that the enumeration problem exists.

Now, try disabling OTG on the microUSB connector of BRK B by setting its role to a peripheral. The original 5.10 devicetree from Octavo contains this:

&usbotg_hs{

u-boot,dm-pre-reloc;

status = "okay";

phys = <&usbphyc_port1 0>;

phy-names = "usb2-phy";

};

Try changing it as follows and rebuilding the kernel:

&usbotg_hs{

u-boot,dm-pre-reloc;

status = "okay";

phys = <&usbphyc_port1 0>;

phy-names = "usb2-phy";

dr_mode = "peripheral";

};

The above is successful if you no longer see the a_alt_hnp_support error. Unfortunately I’m away from my drawer of Octavo hardware until next semester starts so I can’t test this and it’s very much a shot in the dark. If this does eliminate that error and get BRK B to appear in lsusb, then I will post a full explanation of what was happening and we can proceed to worrying about rndis_host.

If that doesn’t get you anywhere, you could also try adding usb-role-switch; and role-switch-default-mode = "peripheral"; to that same devicetree node.

• This reply was modified 1 year, 10 months ago by Aedan Cullen.
• This reply was modified 1 year, 10 months ago by Aedan Cullen.

[Aedan Cullen]

There are two problems here. First, we need to have enumeration on the bus before worrying about RNDIS, but we are not finishing enumeration. (The a_alt_hnp_support failed: -32 error comes from usb_enumerate_device_otg in drivers/usb/core/hub.c.) Lack of RNDIS host support on BRK A may be a problem, but it is a separate problem to worry about after we make it through enumeration.

Investigating that error, I believe the dwc2 driver may have incorrect HNP/SRP attributes in its OTG descriptor when used as a gadget device in kernel 5.10 (that’s the condensed summary of the mess.)

First, verify that you don’t see BRK B in lsusb from BRK A, even though it is connected. This confirms that the enumeration problem exists.

Now, try disabling OTG on the microUSB connector of BRK B by setting its role to a peripheral. The original 5.10 devicetree from Octavo contains this:

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; };

1 2 3 4 5 6

&usbotg_hs{     u-boot,dm-pre-reloc;     status = "okay";     phys = <&usbphyc_port1 0>;     phy-names = "usb2-phy"; };

Try changing it as follows and rebuilding the kernel:

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; dr_mode = "peripheral"; };

1 2 3 4 5 6 7

&usbotg_hs{     u-boot,dm-pre-reloc;     status = "okay";     phys = <&usbphyc_port1 0>;     phy-names = "usb2-phy";     dr_mode = "peripheral"; };

This is successful if you no longer see the a_alt_hnp_support error. Unfortunately I’m away from my drawer of Octavo hardware until next semester starts so I can’t test this and it’s very much a shot in the dark. If this does eliminate that error and get BRK B to appear in lsusb, then I will post a full explanation of what was happening and we can proceed to worrying about rndis_host.

If that doesn’t get you anywhere, you could also try adding usb-role-switch; and role-switch-default-mode = "peripheral"; to that same devicetree node.

[Aedan Cullen]

There are two problems here. First, we need to have enumeration on the bus before worrying about RNDIS, but we are not finishing enumeration. (The set a_alt_hnp_support failed: -32 error comes from usb_enumerate_device_otg in drivers/usb/core/hub.c.) Lack of RNDIS host support on BRK A may be a problem, but it is a separate problem to worry about after we make it through enumeration.

 

Investigating that error, I believe the dwc2 driver may have incorrect HNP/SRP attributes in its OTG descriptor when used as a gadget device in kernel 5.10 (that’s the condensed summary of the mess.)

First, verify that you don’t see BRK B in lsusb from BRK A, even though it is connected. This confirms that the enumeration problem exists.

Now, try disabling OTG on the microUSB connector of BRK B by setting its role to a peripheral. The original 5.10 devicetree from Octavo contains this:

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; };

1 2 3 4 5 6

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; };

Try changing it as follows and rebuilding the kernel:

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; dr_mode = "peripheral"; };

1 2 3 4 5 6 7

&usbotg_hs{ u-boot,dm-pre-reloc; status = "okay"; phys = <&usbphyc_port1 0>; phy-names = "usb2-phy"; dr_mode = "peripheral"; };

This is successful if you no longer see the a_alt_hnp_support error. Unfortunately I’m away from my drawer of Octavo hardware until next semester starts so I can’t test this and it’s very much a shot in the dark. If this does eliminate that error and get BRK B to appear in lsusb, then I will post a full explanation of what was happening and we can proceed to worrying about rndis_host.

If that doesn’t get you anywhere, you could also try adding usb-role-switch; and role-switch-default-mode = "peripheral"; to that same devicetree node.

[Aedan Cullen]

(First, I note that the PMIC_IN_PWR_EN pin on the OSD3358 corresponds to the PWR_EN pin in the TPS65217 datasheet. PMIC_POWER_EN is an output from the AM3358 RTC block, and does keep the same name as in the AM335x datasheet. Maybe we need a standard naming convention for SiP pins…)

PMIC_POWER_EN is always driven high by the RTC block after VDDS_RTC comes up (which is powered by the always-on LDO1 output, called SYS_RTC_1P8V on the OSD3358). Connecting it directly to the PWR_EN input of the PMIC thus starts the power-up sequence of all the other DCDCs and LDOs in the system as soon as the RTC has been powered.

So you should have the system-power-controller entry, as in this use case it is indeed the RTC block in the processor that controls all the main supplies. Furthermore, to disable those supplies, the RTC can drive PWR_EN low for various power-down operations, such as the transition to OFF and SLEEP states of the PMIC (some of this is in drivers/rtc/rtc-omap.c.)

In any case, at least in upstream Linux, am335x-osd3358-sm-red.dts does include system-power-controller.

[Aedan Cullen]

This is a fascinating problem. However, I tried three kernels (5.10.10, 5.4.31, and 4.19.49) and wasn’t able to reproduce this with your script on an OSD32MP1-BRK using either Octavo’s Debian images or ST’s OpenSTLinux. Writes to both TTYs always succeed. This makes me think that it is not an exciting stm32-usart.c driver bug. Maybe there’s some additional detail about your device tree configuration of the USART modules that causes an issue, or a specific way that you’re building your overall Linux system that isn’t replicated in my testing. More information about your specific system might be needed to troubleshoot this problem.

Things that come to mind:

What board are you reproducing this issue on? If you’re only reproducing it with a custom board, have you tried it on one of the standard Octavo boards with nothing connected to the USART pins at all? Are you sure that the issue is not related to hardware flow control (CTS/RTS pins?)

[Aedan Cullen]

This forum isn’t letting me post links, probably to filter spam. The schematic for V2.1 is in an archive called “tidr336.zip” which you can find if you put that into the search box on the TI website. It actually has the PHYs connected both to the PRUs and to the CPSW (the main ethernet switch that you use from the Cortex-A8) so there’s some extra mux stuff on sheet 10 which you likely may not need for your application. I haven’t yet familiarized myself with the configuration of the PRUs here, and it seems that MII is used in that case. But with Linux, RMII is definitely being used – if you Google am335x-icev2.dts and go to line 202, you can see the CPSW pin configuration with RXD0, RXD1, TXD0, TXD1, and the refclk pins.

[Aedan Cullen]

There is indeed an RMII2 reference clock signal, but it’s just not on a pin named RMII2_REF_CLK. Instead, it’s one of the alternate signals available for the pin MII1_COL. That’s the pin you’ll want to use.

(If you search the AM335x datasheet for “rmii2_refclk”, you can see that this signal appears on ball H16 of the ZCZ package, which corresponds to ball F15 on the OSD335x-SM. In Octavo’s schematic symbol for the OSD335x-SM, the pin name is kept as MII1_COL.)

For an example of this usage, you can take a look at TI’s AM335x ICE V2 board, which has two PHYs over RMII. In its devicetree, AM335X_PIN_MII1_COL is set to MUX_MODE1 to use it as the “rmii2_refclk” input.

[Author]

Posts