Vero 4K+ board bring-up and testing

chewitt

Comparing wireless performance between CE 19's vendor kernel (4.9) & LE 11 mainline noticing wireless performance drop-off of at least 1/. I am using a tweaked DTS based on the p231 one for testing.

Here is dmesg, iperf3 results, and /sys/kernel/debug/{mmc2,sdio}/ios.

LE 11 - 5.16.1 - MMC @ 50Mhz (same as p231, except for capabilities):

http://ix.io/3MGY

LE11 - 5.16.1 - MMC @ 100MHz:

http://ix.io/3MGZ

CE 19 - 4.9.113 (vendor kernel) - MMC @ 100MHz (in DT, but debug says 200MHz):

http://ix.io/3MH0

Here is the DTS I am working with so far:

/dts-v1/;

#include "meson-gxl-s905d-p231.dts"

/ {
   compatible = "osmc,vero-4k-plus", "amlogic,s905d", "amlogic,meson-gxl";
   model = "OSMC Vero 4K+";

   leds {
      compatible = "gpio-leds";

      led-power {
         label = "power";
         gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
         default-state = "on";
      };
   };
};

/* SDIO */
&sd_emmc_a {
   cap-sd-highspeed;
   sd-uhs-sdr12;
   sd-uhs-sdr25;
   sd-uhs-sdr50;
   sd-uhs-sdr104;
   max-frequency = <100000000>;
};

&uart_A {
   status = "okay";
   pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
   pinctrl-names = "default";
   uart-has-rtscts;

   bluetooth {
      compatible = "brcm,bcm43438-bt";
      shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
      max-speed = <2000000>;
      clocks = <&wifi32k>;
      clock-names = "lpo";
   };
};

Quote from chewitt

Thanks. Can I ask you to drop the sd-uhs* caps from the node and repeat the 'after' test. Although things are 'detected' I'm not sure it makes any difference and it's always best to submit minimal changes upstream.

Without the uhs caps, the driver won't even register the 100Mhz clock (it stays at 50Mhz) (see here). On a side note, from what I could tell looking at the 4.9 DT & driver code, the sdio.f_max node is what drives the max frequency.

AP6255 package supports up to 208MHz clock in SDR104 timing. It seems with upstream drivers it performs like a 100MHz clock.

All three package options of the WLAN section provide support for SDIO version 3.0 
including the new UHS-I modes: 
 DS: Default speed up to 25MHz (3.3V signaling). 
 HS: High speed up to 50MH (3.3V signaling). 
 SDR12: SDR up to 25MHz (1.8V signaling). 
 SDR25: SDR up to 50MHz (1.8V signaling). 
 SDR50: SDR up to 100MHz (1.8V signaling). 
 SDR104: SDR up to 208MHz (1.8V signaling). 
 DDR50: DDR up to 50MHz (1.8V signaling). 

Quote from chewitt

Random Q .. are you sure that you have the Vero 4k plus? .. You've used the p231 dts as the base and this uses internal PHY (should be 10/100) where the plus (according to the website) has Gigabit which would be using the external PHY and p230 would be the right dts base. I think you have the 4k (non-plus) model. I'm no expert on OSMC hardware though

It's a 4k+, the original DTS is based on the non-plus and it has an "amlogic-dt-id = gxl_p231_2g" which is probably where I picked it up from. But it does override the ethernet node and probably points over to the external PHY. The 4k is pointed to the p212 as the baseline, so I think it is an S905X? Not sure about that.

I never used the Ethernet, but your right p231 appears to be pointing at the internal PHY (which ethtool says is 100Mbit), and using the p230 does point to the external PHY (which ethtool says is 1000Mbit). I'll have to delete some of the entries on the p230, since the device doesn't have any keys (unless it's the recovery mode button in the 3.5mm audio jack), and there is no power indicator on GPIOAO_2.

It doesn't really change the wireless situation, and there is an IRQ 51 warning, and no change on MPEG2:

http://ix.io/3MLC

As a side note, the ethernet MAC has an OUI for Shenzhen Amediatech Technology Co, which appears to be OEM on a number of the x96 variants:

SHENZHEN AMEDIATECH TECHNOLOGY CO., LTD FCC Filings

So it might line up with one of those. I'll take another look at the original DTS delivered with the 4.9 kernel, linking those below for reference:

vero3plus_2g_16g.dts:

http://ix.io/3MLG

vero3_2g_16g.dts:

http://ix.io/3MLI

Here is the updated dts, based on p230:

http://ix.io/3MLX

As a side note, here is pastekodi with playback of MPEG-2:

http://ix.io/3MLW

Quote from chewitt

I'd be interested in what dmesg shows with an update to https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar and a switch to the dts that I created "meson-gxl-s905d-vero4k-plus.dtb" .. I pushed new images to https://chewitt.libreelec.tv/testing/ - this time they have the dtb files present.

Yeah, this is working. However, ethernet is pointing at the internal PHY and not the external PHY (Gigabit). I am pretty sure the internal PHY is connected to nothing externally.

http://ix.io/3MMG

hcitool dev shows BT MAC, Wifi is OK (half speed to vendor kernel, but works), haven't tested Ethernet (been too lazy to buy a 30ft cable to run it around the room to the switch, and wifi is fine for playblack with a Kodi buffercache -- even at 120Mbit).

The standby led doesn't turn off, can that be defined, this is by default off. I think I can toggle it via /sys/class/*/trigger. It's normally a red led, it is typically ON when the device is in standby/powered off and driven OFF when the DT loads, if you need to follow the naming standards.

+	leds {
+		compatible = "gpio-leds";
+
+		led-standby {
+			label = "standby";
+			gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_LOW>;
+			default-state = "off";
+		};
+	};

Quote from chewitt

I set the p230 style external PHY setup for Ethernet and changed the LED config around. I'd like to see what this looks like if possible.

I am noticing that it appears the framebuffer is shifted 1/4 of the screen up, this was fine with the p231 DTS and I believe it was fine with the p230 DTS. So oddly, I am not sure if the update applied because there is a splash screen in u-boot that never goes away until it boots up the kernel normally. Before I was seeing the update stage, reboot, etc.

The other reason I don't think the update has applied is kernel still indicates internal PHY, and ethtool says 100Mbit:

[ 8.408898] meson8b-dwmac c9410000.ethernet eth0: PHY [0.e40908ff:08] driver [Meson GXL Internal PHY] (irq=51)

Or maybe this is still an old build?

Edit: OK, it appears to be your kernel build, maybe some extra patches? I dropped back in 5.16.1 mainline and FB is OK now.

Edit 2: Ran with the p230 DTS ethernet settings, can confirm Gigabit works, links, and iperf3 is 950Mbit/s. So those should work.

Screenshot of the console FB issue:

Screenshot of the LED after booting:

Frame buffer issue appears to be related to commit 3fce7e121f1729948b511fa05030ffca3e88d092 on your branch, reverted that and FB is working properly. I am guessing it is MESON_DRM and it doesn't load early enough as a module.

Here is a patch on top of your DTS changes, which resolves:

• Standby LED for 4k+ (goes off when DT is loaded, on when device is in standby)
• Gigabit for 4k+
• Moved the power button to the 4k, 4k+ has an LED but it is inverted from the 4k and no power button [didn't know the 4K had one]

There is apparently a story with people being annoyed by the LED, so apparently in the 4K+ it is inverted when the device is plugged in but "powered off" the light is on, but when it is running normally the light is off. This is also used as a fault indicator if something goes wrong in early boot (u-boot) or filesystems don't mount. Feel free to squash these in, although can't promise I followed kernel coding standards.

http://ix.io/3MPb (there is actually a mistake there, the include for dt-bindings/input/input.h should probably be moved as well to the 4k dts, but let you settle in on how you want to submit it)

And here is dmesg + iperf3 (showing Gigabit NIC working):

http://ix.io/3MPc

Quote from chewitt

The image I shared had similar changes already applied .. I hadn't pushed the patches to repos. Nice to confirm that the Ethernet works with the normal conventions and has good speed (would be nice to solve the IRQ splat though).

Ahh, OK. It seems like the images didn't pick up that patch, so maybe not integrated from the kernel tree? I did test them, but the PHY was still internal. Once I couldn't get that to work with that image, went poking in what you had pushed to Github to figure out the framebuffer issue.

That IRQ splat is connected with &external_mdio. Removing the interrupt properties solves that. I don't think the interrupt line define is right, maybe it is shared with the internal phy?

Speaking of that, there is an GPIO->IRQ for the aml_wifi to trigger a host wakeup, I believe, which may be a contributor for performance. I believe it is some sort of out-of-band wake up? That is on GPIOX_7, and in aml_wifi is converted to an IRQ apparently. Couldn't see a direct connection of how the interrupt handler is registered, but hard to understand when you never have done linux embedded programming :). I miss the 6502, it was simple, write to memory your interrupt handler address, and that was it :).

Quote from chewitt

4K+ has no LEDs when powered OFF, blue remains off when powered ON, red when panic is flagged.

I have never seen it behave that way with OSMC, perhaps they changed the behavior. I recall seeing threads of people complaining about the LED, "too distracting". Personally, as long as it is visibile to /sys/class/leds then I should be able to trigger it off.

Quote from chewitt

I don't see two LEDs, it looks like single multi-colour one, although it looks more like an IR sensor than anything else. Is the IR sensor only via the extension cable at the back I wonder?

Yeah, not sure about the multi-colour, there is only one LED physically IIRC, and there is another sensor right next to it physically (which I believe the silkscreen said IR, it's been a while since I have cracked it open). There is also an external IR sensor delivered with the device, but oddly the remote uses a dongle.

Quote from chewitt

Can you dump the factory device-tree with dtc to pastebin or a file?

01_dtbdump_Vero4K.dtb via "dtc -O dts" (Vero 4K):

http://ix.io/3MTn

02_dtbdump_Vero4KPlus.dtb via "dtc -O dts" (Vero 4K+):

http://ix.io/3MTp

OSMC 4.9 vendor kernel output of interrupts, gpio, pwm:

http://ix.io/3MTq

Dug a bit more into missing GPIO/IRQ for wifi, and it appears to a PM "wake up", so not too worried about that. I doubt it has anything to do with WiFi performance, it probably is the "DMA" issue.

Wifi is working, and it is respectable and usable, the Pi 4 can't even hit those speeds since the SDIO bus gated at 50Mhz IIRC (it's caps out at ~80Mbps on Pi 4, I think it's basically 50Mhz * 4 data bits / 2 for duplex -- since it's half duplex a theoretical 100Mbps?). At 100MHz, I would expect a 200Mbps speed less maybe 20% (~160Mbps) if the overhead numbers for the Pi track over. At 125Mbps it's pretty close, and if they figure out the DMA issue eventually I'll circle back and see where it's at, it almost sounds like perhaps some devices do not send aligned/padding frames like the mmc host driver is expecting.

Quote from chewitt

Vero4k is indeed p212 and Vero4k+ claims to be p231 but looks like the upstream p230 and inherits most of it's content from the Vero4k/p212 tree so

Yeah, the recovery image is Android 7.1 reporting "ro.product.name=p230", "ro.product.model=X96", "ro.product.brand=Amlogic" in the default.prop.

Quote from chewitt

I can't see anything unusual in the external_mdio node but then I have no clue about IRQ/interrupt stuff.. it sounds likee you know way more than me

LOL, I know it was simpler in the 80's Kernel hacking is quite the daunting task, I know enough to make bad assumptions based on things I understand conceptually but it's so time consuming trying to trace through the code and understand what's going on. I am sure it is like a lot of big/complex software where you can spend an entire career working on it and still not know every subsystem, but those guys certainly have brought it a long ways since the 1.2 kernel days when I started with Linux.

I think the IRQ splat is because there is no driver code actually registered to the IRQ, but the IRQ is registered to the kernel via the DT.

Quote from chewitt

I've updated the box image and tar file in my share and pushed updated patches to kernel/LE branches. Boot logs appreciated..

http://ix.io/3MXT

Looks good, other than the IRQ. Light does turn off at boot.