Posts by frakkin64

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

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

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:

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";
+		};
+	};

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

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

Maybe posting an mkvinfo of the video file and someone could tell if it is indexed or not? I am not certain, but I think the entry is "Seek head" table?

Quote from zehner

sorry, no answer there, because they don't explain, why they have changed this behaviour in the middle of the lifetime of the soc.

There is an entire blog post about it, which explains the why, and OF COURSE software changes during the lifetime of the SoC. If it doesn't then you have an Amlogic device running a 3.14 kernel.

Bullseye - the new version of Raspberry Pi OS - Raspberry Pi

Every two years, Debian Linux, on which Raspberry Pi OS is based, gets a major upgrade. 'Bullseye' is named after Woody's horse in Toy Story 2

www.raspberrypi.com

Quote

KMS video driver

The KMS (kernel modesetting) driver, which was an experimental option in previous releases, is now the standard video driver in this release.

KMS is the Linux standard mechanism for controlling the connection to a display. The previous video driver was Raspberry Pi-specific, and was built into the custom firmware which is unique to Raspberry Pi computers; it was also closed source. This enabled us to make a number of optimisations for our hardware, but it also meant that any applications that wanted to directly access the display needed to be written specifically for Raspberry Pi. By moving to KMS, any application written using the standard Linux display APIs should run on Raspberry Pi without modification.

The other advantage of this approach is that display drivers for Raspberry Pi are now all part of the Linux kernel, and can therefore be written or modified by third parties; previously this code was all in the closed-source firmware. This should make it easier for the manufacturers of items like custom displays to add support for Raspberry Pi.

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 Lain

Are you saying when you do a 40min jump ahead in an MKV video it instantly starts playing?

Yeah, it's maybe a 250ms delay, but it's pretty instant. For example, a 27GB HEVC 4k video, seeking an hour into it, no problem maybe 250ms. This is from an RPi4, connected over Wi-Fi, to NFS on my Ubuntu AMD FX8350 box. I am using a NFS source in Kodi 19.

I think as popcornmix suggested you might want to look at your media files and make sure everything is OK there, most of my media is MKV and seeking is pretty much instant.

Maybe test your network speed with iperf3 at various points to your QNAP. Might be your read/write size needs to be adjusted, or mount options.

95MB/s, that's pretty respectable. If you have some other network usage/congestion, your pretty much within the upper limit of Gigabit around 800Mbit/s. The other thing to consider is bus limitations, CPU usage, etc within the receiving device as well.

Some simple testing with non-cached files below, but this is between 2 AMD64 boxes (Ryzen 5 & FX 8350).

Over NFS:

dd if=/srv/media/movies/X2\ \(2003\)/X2\ \(2003\)\ 720p\ AAC.mp4 of=/dev/null bs=8192

326423+1 records in

326423+1 records out

2674058398 bytes (2.7 GB, 2.5 GiB) copied, 24.7901 s, 108 MB/s

Local:

dd if=/srv/media/movies/X-Men\ Origins\ -\ Wolverine\ \(2009\)/X-Men\ Origins\ -\ Wolverine\ \(2009\)\ 720p\ AAC.mp4 of=/dev/null bs=8192

263663+1 records in

263663+1 records out

2159933396 bytes (2.2 GB, 2.0 GiB) copied, 8.29314 s, 260 MB/s

Iperf3 (suggests there is little NFS overhead @ ~112MB/s -- but you still have Ethernet/IP/TCP overhead)

Connecting to host 192.168.0.10, port 5201

Reverse mode, remote host 192.168.0.10 is sending

[ 5] local 192.168.0.1 port 43988 connected to 192.168.0.10 port 5201

[ ID] Interval Transfer Bitrate

[ 5] 0.00-1.00 sec 112 MBytes 942 Mbits/sec

[ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec

[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec

[ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec

[ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec

[ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec

[ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec

[ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec

[ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec

[ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender

[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver

Quote from chewitt

Can I ask you to run some proper before/after iperf tests with the 50MHz > 100MHz change (only), then a test with any other changes (and share the dts diff) and then start a new thread with the results in a post that I can link to.

CE w/ 4.9 vendor kernel reports 200MHz, wonder if it is overclocked. Looked at the DTS there and it seems the MMC is using 100MHz. But I wouldn't put it past that Amlogic code to ignore the DT and just use hardcoded values. The other thing is the capabilities suggest HS200 even though sdio debug reports SDR104. In any case, I posted it over at:

Thread

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):

…

frakkin64

January 18, 2022 at 5:11 PM

100Mhz vs 200Mhz on 5.16 performs the same.

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

See https://github.com/torvalds/linux…a3c0cb287f6e223 for some history on the alignment message. I think it needs to be solved in brcmfmac? - I'll ask maintainers again. The p231 dts inherits 50MHz from https://github.com/torvalds/linux…-q20x.dtsi#L262 as most of the reference boards have slow speeds set. The solution for that might be to create an upstream board dts for Vero4+ that sets higher SDIO clock. Can you share "dmesg | paste" please.

I bumped the SDIO clock to 200MHz and SDR104 timing spec. It's pushing about 125Mbit/s now. This is dmesg running on vanilla p231 without the dts changes:

http://ix.io/3MEm

Quote from chewitt

MPEG2 should be supported (the codec is upstream) but no idea what state it's in - I'll have to go create media to test it.

I can capture a Kodi debug log, but the audio decoding is running but the video just shows the media library (no playback is shown). But as it is without MPEG2 it is reasonably usable.

Another option is using the gpio-shutdown overlay + systemd service in the appropriate target (sounds like it is shutdown.target).

firmware/README at 175984a6dc4c321553e295cf9679a6020231caf4 · raspberrypi/firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. -…

github.com

Quote from chewitt

That's a good/bad thing; it's it's the thing we need most, but their downstream drivers are extremely complicated with lots of features and the lack of anything upstream creates the opportunity to apply the "less is more" principle and implement only the capbilities we actually need.

Yes, that is good news indeed. I wonder if the work already done has forced their hand or maybe Google did. I would think some of the mainline work would complicate porting forward their code base.

A few things I noticed so far are:

- Wireless seems to runs at maybe 1/3 speed, 80~96Mbit/s on a 5GHz channel @ 80 Mhz, should be around ~225 with CE. Wondering if the SDIO bus is driven at a lower clock frequency and maybe DTB tweaking would solve it? Running with the p231 DTB for the Vero 4K+. There are complaints about the CLM blob & firmware files, not sure if that is relevant or not, it is a Broadcom 43455 according to the drivers on both CE & LE. But it does work.

- MPEG2 HW decoding doesn't display anything (maybe not implemented?), but H264 & H265 seemed to be fine.

Edit:

Wireless slowness is probably related to this:

[ 16.337223] meson-gx-mmc d0070000.mmc: unaligned sg len 304 blksize 512, disabling descriptor DMA for transfer

kworker is running 8% CPU, sounds like it is bit-banging the SDIO bus. I did get the SDIO bus (mmc2) into SDR104 @ 200MHz, it was HS @ 50MHz with the p231 DTB.

The progress so far is pretty impressive, haven't done extensive testing. But it appears GXL S905D is working well, I'll have to give it a bit more of a go next week and see what shakes loose (other than the "shimmer" issue, playback of h264/hevc samples indicated DRMPRIME and nothing was noticeable). RPi4 is my daily driver, but I have a Vero 4K+ in my home office for background noise while working.

Is Amlogic actually upstreaming any of their newer devices? Or are they going the Realtek route?

I submitted a PR to add a variant of vpeter4's script to LE11.

kodi: add shutdown hook to autostart by wagnerch · Pull Request #6142 · LibreELEC/LibreELEC.tv

This adds an "autostop.sh" script, which is based on the conversation and related threads here. The kodi-autostart.service already has…

github.com