10 10

About This Club

Running Armbian on all kinds of ARM based TV boxes. Select a topic clicking on a tab above. If you are new to Armbian for TV boxes you should start by reading the FAQ entry "Status of Armbian on TV boxes - Please read first": https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
  1. What's new in this club
  2. Look at the post edit I made a little after, clarifies why the thing can't work on our tv boxes. I learned things are and there on the internet, could not find a proper guide. Anyway google reports this forum thread, which is a good starting point: Yeah, undervolting is cool, but results vary a lot depending on the cpu sample. GPU can be tweaked too. RAM can't be tweaked for three reasons: the dmc (dram memory controller) node in the dtb is disabled the dmc driver in the kernel is a bit broken the piece of code that does the dram frequency scaling is not present The dram frequency is fixed by a thing which is called ddrbin, and it is the very first thing that boots (even before u-boot). It is fixed to 330 Mhz currently, but probably I will push it to a higher yet safe value. You need to put together an idbloader, which is composed of ddrbin + u-boot SPL. You can inspect armbian sources for that, but if you're not an expert in compiling u-boot, I would rather suggest you to stay away from that to avoid lose mental sanity.
  3. Thank y for the quick respond , your excellent work!! I dont understand to much about how DTB syntax works. Trying to learn , where are good sources for learning? Maybe if you have time you can set up a little guide. I also tried to undervolt CPU. Converted HEX to DES for easier reading. Found this setting to working well up to 1.5Ghz Tried to tweak some RAM and GPU settings , but dont think they work. Do you know a way to show RAM frequency from terminal ? dmesg ?. I do DD benchmark on /tmp and sysbench --test=memory run from sysbench tool. No changes in performance enable /disabling settings for RAM and GPU. I recommend hardinfo to show HWinfo. Are RAM frequency set by uboot ? If yes , how can I test different setting for RAM in uboot ? Links to DTB and DTS. opp-1200000000 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <1200000>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1296000000 { opp-hz = <0x00 0x4d3f6400>; opp-microvolt = <1225000>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1392000000 { opp-hz = <0x00 0x52f83c00>; opp-microvolt = <1250000>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1512000000 { opp-hz = <0x00 0x5a1f4a00>; opp-microvolt = <1350000>; // opp-microvolt = <0x149970>; clock-latency-ns = <0x9c40>; };
  4. You are not going to get watchable YouTube on a cheap TV box with Armbian currently. The state of the open source video decoders (vs the generally closed source used in Android) is still a work in process. Right now I would say the best supported CPUs are the Rockchip ones. On the box side balbes150 is working on the Station M1/P1 and jock is working on general Rockchip TV box support.
  5. @Gausus thank for sharing that tip. The main problem I see with your approach is that the vqmmc supply is wired to sdmmcio-regulator, which in turn is not really wired to a proper gpio pin controller. This line: gpios = <0x68 0x00 0x00>; Converts into: gpios = <&pcfg-pull-none-2ma RK_PA0 GPIO_ACTIVE_HIGH>; which does not make sense, since pcfg-pull-none-2ma is not a GPIO controller. There is not real voltage switching to 1.8v for the sdcard controller part as required by UHS modes, in your case the sdcard is incidentally working in UHS mode with 3.3v for the signalling part, but another card may not work or may not be stable. By the way, looking into rk3328-roc-cc device tree there is some reference about sdmmcio regulator, and it is wired to the SoC General Register File (GRF), so it could be possible for any rk3318/rk3328 board to achieve UHS speed modes. This is a good catch, because any rk3318 original firmware allows this, thus the original dtbs never expose such capability. I will look into! edit: hmmm, this definitely looks like a red herring. I followed the rk3328-roc-cc approach but, after measuring the voltage on the sdcard pins, the regulator is not really changing voltage. In fact, some sdcard are happily recognized and work in UHS mode with 3.3v, some others absolutely don't (a couple of Sandisk ones) because require the 1.8v, as specs say. Then I found this discussion: https://www.spinics.net/lists/arm-kernel/msg783365.html where is stated that Firefly (the guys behind roc-cc board) rewired the GRF gpio pin (which is normally used to mute the analog audio) to the sdmmc_io pin. That's it, the roc-cc (which is the same board in station m1) has a custom design for that pin that switches between 1.8v and 3.3v. So on tv boxes that pin enables and disables analog audio signal, on the roc-cc switches the sdmmc io regulator.
  6. DTB SDCARD mode up to 104 MB/s Have tried to squeeze some more performance out of my H96 max + RK3328. SDCARD speed runs at sd high-speed mode / max 24MB/s R∕W on rk3318-box.dtb Its possible to get higher speed from sd-card # Org DTB sudo cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (dont care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) Have modified the dtb to support up to hr104 (104 MB/s) rk3318 image will not boot , but Armbian_21.11.0-trunk_Station-m1_hirsute_edge_5.14.11_xfce_desktop.img are booting using this modified DTB DTS # Mod DTB Station m1 image sudo cat /sys/kernel/debug/mmc0/ios clock: 150000000 Hz actual clock: 150000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (dont care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) Using gnome-disks performance tool , i get 70+ read 40+ write speed. about 2-3X performance boost on sdcard. If y like to test this DTB disable all overlays in /boot/extlinux/extlinux.conf Have tried to enable modules in rk3318 image to boot. APPEND root= xxx yyy .... ADD to end mmc_block sdhci tifm_sd Dont know if kernel need a patch to boot from sdacrd when sd-uhs-XX modes enabled. SOME links about sdcard mode i DTB https://android.googlesource.com/kernel/msm/+/android-wear-5.1.1_r0.6/Documentation/devicetree/bindings/mmc/mmc.txt https://patchwork.kernel.org/project/linux-arm-kernel/patch/87imkryz5t.fsf@vany.ca/ https://tinkerboarding.co.uk/forum/archive/index.php/thread-310.html Changed i rk3318-box.dtb mmc@ff500000 { compatible = "rockchip,rk3328-dw-mshc\0rockchip,rk3288-dw-mshc"; reg = <0x00 0xff500000 0x00 0x4000>; interrupts = <0x00 0x0c 0x04>; clocks = <0x02 0x13d 0x02 0x21 0x02 0x4a 0x02 0x4e>; clock-names = "biu\0ciu\0ciu-drive\0ciu-sample"; fifo-depth = <0x100>; max-frequency = <0x8f0d180>; resets = <0x02 0x6d>; reset-names = "reset"; status = "okay"; bus-width = <0x04>; cap-mmc-highspeed; cap-sd-highspeed; disable-wp; pinctrl-names = "default"; pinctrl-0 = <0x49 0x4a 0x4b 0x4c>; sd-uhs-sdr12; <-------------------------- sd-uhs-sdr25; <-------------------------- sd-uhs-sdr50; <-------------------------- sd-uhs-sdr104; <-------------------------- vmmc-supply = <0x4d>; vqmmc-supply = <0xd4>; <-------------------------- DISABLED phandle = d4 spdif-2 could not find l free phandle to use card-detect-delay = <0x320>; // Diff / Disabled // phandle = <0x9a>; // card-detect-delay = <0x320>; // cd-gpios = <0x48 0x05 0x01>; // no-sdio; // supports-sd; }; sdmmc-regulator { compatible = "regulator-fixed"; gpio = <0x6b 0x1e 0x01>; pinctrl-names = "default"; pinctrl-0 = <0x6c>; regulator-name = "vcc_sd"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <0x325aa0>; regulator-max-microvolt = <0x325aa0>; vin-supply = <0x1e>; phandle = <0x4d>; }; // ADD high speed sdcard 1,8v mode sdmmcio-regulator { compatible = "regulator-gpio"; gpios = <0x68 0x00 0x00>; states = <0x1b7740 0x01 0x325aa0 0x00>; regulator-name = "vcc_sdio"; regulator-type = "voltage"; regulator-min-microvolt = <0x1b7740>; regulator-max-microvolt = <0x325aa0>; regulator-always-on; // vin-supply = <0x2b>; vin-supply = <0x6e>; phandle = <0xd4>; }; // spdif-2 { // // spdifm2-tx { // rockchip,pins = <0x00 0x02 0x02 0x5f>; // phandle = <0xd4>; // }; // };
  7. @SteeMan My only need is youtube, some national tv-app and sometimes a email or a document, not more than that. The reason Im considering armbian in this device is that the android9 version has locked out split screen so I would be able staying with android if I find a way to enable split screen, would you happen to know any tips about android 9 /split screen ? Is RK-cpus the widest supported tv box on armbian ? I have been looking around this forum but cant really find a general favourite ?
  8. @jhg I understand the fascination, it is why I'm here trying to help others foster that same fascination. But I would caution you on your expectations. When you talk about 'desktop computer' you are likely to be disappointed. The current state of these boxes (once you get one working) is you can get a desktop gui running, but the performance isn't going to be something useful. They do make great servers however. If you want a usable desktop experience you are going to need to be spending around a $100 or so for an RK3399 box which is less fascinating and a stretch on the wallet.
  9. @SteeMan Yes, the 610 was the first dtb I tried as that was recommended somewhere around here for the 905x3 but you are right, I should investigate that further. Thank you for tips and patience.
  10. @jhg FYI the s905x3 cpu should be using a meson-sm1-* dtb. sm1 is the internal code for the x3 (glx is the s905 and g12 is the x2 family). So I would recommend starting to test with: meson-sm1-sei610.dtb
  11. @SteeMan Ok. Thank you for assistance, soldering connectors is beyond my interest in this hobby but we did try =0) Let me know if you come to think of anything easier to try. Is there a tv box you can recommend still supported by armbian ? Im fascinated by making a desktop computer out of these and want to see it work, cant really explain why.
  12. @jhg If you really want to dig into this more, you would need to hook up to the colsole interface on your box. To do this you would need to identify the console connector location on the board, solder a connector to it and then get a usb adapter to monitor the low level u-boot output. The first stages of uboot output to the console only, then the chain loaded uboot (uboot.ext) will display stuff at later stages to hdmi.
  13. @SteeMan Thank you for reply, apologies for my late return as Iam not allowed posting more than one post per day for safety reasons. Thank you for clear instructions in your linked post, that is more or less how I understood balbes instructions but you made a clear indefinite procedure so we are on the same page. When using your method I got same result as previously, the A95X logo flashing every 5 seconds and nothing more for 10-20 minutes, no linux boot scripts rolling on the screen, BUT, when going back to balbes ext-linux conf and booting normally (without toothpick) leaving the sd card in the box I got to my surprise some kind of success, the tv went black and I could see the amlogic box thinking about something but after 10-20 minutes still nothing, no boot text, no error message, nothing. This is success in that way that I hate the a95x boot flash video played on max volume so a completely silent a95 box is success and I have never got the a95 box to respond to the sd card before using your structure. The only dtb file giving any response is the meson-gxl-s905x-p212.dtb, Im unsure if I have tested all dtb files but Im getting there...sooo... I guess it is up to finding correct dtb ? Is there any way to get more precise in my troubleshooting, is there log files or similar I can read somewhere as in linux ? I have no worries about bricking the android box, it will be smashed to pieces soon as my patience is ending, when Im out of patience with something it will be smashed to small pieces just to get me piece of mind enabling me to forgive and forget. One thing Ive been thinking about is that balena etcher always fails writing the image file complaining about the armbian files but writing same image with good old rufus always works, I cant see how that would cause any boot issues but its odd, I tried writing with winimage and that worked to with same files balena is nagging about but takes forever, hence rufus. Edit : When reading my first post here I realize I dont get the error message of map file anymore but I have no knowledge judging if that is good or bad, prolly I just got the correct u-boot.etx script for the s905x3 ? Edit 2 : Thank you for assistance (forgot to thank you).
  14. Looks like the existing boot firmware on the emmc, for whatever reason, does not tolerate a valid MSDOS MBR on the emmc. If this is still valid, you can certainly replace the existing firmware with a suitable one, but since a functioning solution has already been worked out, it is certainly easier to use it.
  15. @usual user I run the test: [1] eMMC before change: # xxd -a -g 1 -l 512 /dev/mmcblk1 00000000: 1a e6 31 39 74 02 1f 27 93 be e3 cd 29 12 1b 71 ..19t..'....)..q 00000010: 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 @AML....@....... 00000020: 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 ....@.......`... 00000030: 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 ....@........... 00000040: 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 ................ 00000050: fe 26 6e ba 84 e6 69 fc 6b 79 97 2c 0c 8a b3 15 .&n...i.ky.,.... 00000060: 13 70 39 86 a3 e4 b1 78 22 b4 9b b3 cf 65 88 9c .p9....x"....e.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [2] write 0x55 0xaa to the last 2 bytes of 1st sector: echo -n -e '\x55\xaa' | dd if=/dev/stdin of=/dev/mmcblk1 bs=1 seek=$((512-2)) count=2 conv=notrunc [3] eMMC after change: # xxd -a -g 1 -l 512 /dev/mmcblk1 00000000: 1a e6 31 39 74 02 1f 27 93 be e3 cd 29 12 1b 71 ..19t..'....)..q 00000010: 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 @AML....@....... 00000020: 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 ....@.......`... 00000030: 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 ....@........... 00000040: 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 ................ 00000050: fe 26 6e ba 84 e6 69 fc 6b 79 97 2c 0c 8a b3 15 .&n...i.ky.,.... 00000060: 13 70 39 86 a3 e4 b1 78 22 b4 9b b3 cf 65 88 9c .p9....x"....e.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U. [4] serial terminal: ~$ sudo -i root@buffy:~# stty -F /dev/ttyUSB0 cs8 -parenb cstopb crtscts root@buffy:~# picocom -b 115200 -d 8 -y n -p 1 -f n /dev/ttyUSB0 [5] reboot, and the serial shows: GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:1; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:2; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:3; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:4; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;...
  16. same things where is "first run" scripts located?
  17. @usual user > AFAIS you have inserted a populated partition table. Yes, that was my intention. > Maybe the boot firmware now changes the boot flow I doubt it does. AFAIK: the ROM uses secure-boot using 3 pieces BL1 (is in ROM), BL2 (in 1st sector on emmc), and BL3 is the u-boot. BL2 is also signed. With s905 Amlogic doesn't use regular partitions (e.g: 'mmc part' will give you "no partitions found", and 'fatload' etc. commands won't work either). Amlogic does maintain some kind of partition table. Based on the u-boot messages: mmc read lba=0x12000, blocks=0x2 mmc read lba=0x12002, blocks=0x2 mmc_read_partition_tbl: mmc read partition OK! eMMC/TSD partition table have been checked OK! gxb_p200_v1#mmc read 0x1200000 0x12000 0x400 gxb_p200_v1#md.b 0x1200000 0x400 01200000: 4d 50 54 00 30 31 2e 30 30 2e 30 30 00 00 00 00 MPT.01.00.00.... 01200010: 0e 00 00 00 ca 70 f2 de 62 6f 6f 74 6c 6f 61 64 .....p..bootload 01200020: 65 72 00 00 00 00 00 00 00 00 40 00 00 00 00 00 er........@..... 01200030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01200040: 72 65 73 65 72 76 65 64 00 00 00 00 00 00 00 00 reserved........ 01200050: 00 00 00 04 00 00 00 00 00 00 40 02 00 00 00 00 ..........@..... 01200060: 00 00 00 00 00 00 00 00 63 61 63 68 65 00 00 00 ........cache... 01200070: 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 ........... .... 01200080: 00 00 c0 06 00 00 00 00 02 00 00 00 00 00 00 00 ................ 01200090: 65 6e 76 00 00 00 00 00 00 00 00 00 00 00 00 00 env............. 012000a0: 00 00 80 00 00 00 00 00 00 00 40 27 00 00 00 00 ..........@'.... 012000b0: 00 00 00 00 00 00 00 00 6c 6f 67 6f 00 00 00 00 ........logo.... 012000c0: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 ................ 012000d0: 00 00 40 28 00 00 00 00 01 00 00 00 00 00 00 00 ..@(............ 012000e0: 72 65 63 6f 76 65 72 79 00 00 00 00 00 00 00 00 recovery........ 012000f0: 00 00 00 02 00 00 00 00 00 00 c0 2a 00 00 00 00 ...........*.... ... Amlogic made modifications to u-boot (they even have their own commands 'amlmmc' to read/write the emmc. So, I don't think they would or could modify the boot flow. > just add the boot signature "55AA" to the last two bytes of the sector OK, I will try.
  18. @hexdump I'm using this one: https://github.com/natinusala/linux-amlogic-toolkit I've tried two others, but only this one worked. (Has the script updated). Yes, I have to ground the emmc clock pin while powering up. You will need to add a line to /etc/udev/rules.d: SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1b8e", ATTR{idProduct}=="c003", MODE:="0666", SYMLINK+="worldcup". Plugin OTG USB, Short the pin, power-up, remove the short, and lsusb will show a new Amlogic device. 1st time you need to let the tool unpack your firmware, after this just exec the 'flash' script. Here is the last part of the dbg log I still have on my screen: Writing system partition Command -> /home/pista/amlburn/linux-amlogic-toolkit-master/bin/aml-linux-usb-burn/tools/update 2>/dev/null partition system /home/pista/amlburn/linux-amlogic-toolkit-master/output/image/system.PARTITION - Results --------------------------------------------------- [update]sparse format detected file size is 0x3e01502c AmlUsbTplCmd = download store system sparse 0x3e01502c rettemp = 1 buffer = download store system sparse 0x3e01502c AmlUsbReadStatus retusb = 1 Downloading.... [update]Cost time 80Sec [update]Transfer size 0x3e01502cB(992MB) AmlUsbBulkCmd[download get_status] [update]mwrite success ------------------------------------------------------------- [OK] Done
  19. AFAIS you have inserted a populated partition table. Maybe the boot firmware now changes the boot flow according these values. To confirm that the presence of an MSDOS MBR already triggers it, just add the boot signature "55AA" to the last two bytes of the sector. If booting still does not work with an otherwise empty partition table, no MSDOS MBR can be used unless the existing boot firmware is also adapted.
  20. @hexdump Yes, I've learned about this option from your post in an other thread. Also people from the NXP processor forum mentioned this. It was the one option I didn't try. I guess it would be worth... shouldn't be much work and there is no chance to brick again. @TonyMac32 has git of the old Amlogic u-boot, and I see the gpt command does exist in this version, but it is not available on my TV box, so the question is whether GPT support is enabled. I probably try it later today...
  21. @pista - i guess your theory about the checksum is correct then ... which linux version of the usb burning tool for amlogic did you use btw.? do you have to ground the emmc clock pin to get it recognized there or is it recognized if bricked even without that?
  22. @pista - just to mention it here: i'm aware of one other type of system with a strange boot setup: the rk3288 based chromebooks (veyron) are using gpt partitoning, which consists of the primary gpt partition table at the beginning of the disk (and spanning even more space then the traditional mbr partition table) and a backup gpt partition table at the end of the disk (a normal redunadancy measure of gpt partioning) ... the strange thing on those chromebooks is that you can create a gpt partition table successflly, but if you try to read it back it tells you that the primary gpt table is corrupted (not sure where this gets lost, but its consistent) ... the way i got it working was to write the gpt table and then boot the kernel with the "gpt" option, which tells it to use the backup gpt table if the primary one is corrupted - u-boot is complaining a lot about the broken primary gpt, but works in this case (i just commented out those warning from u.boot for it) ... i think there are patches for those chromebooks, which put the primare gpt table to another place, but my approach works without those patches maybe an approach like this might work for the s905 too - not sure, but your approach is fine too i guess (maybe the gpt one would be a bit more standard - if it works at all in this case ) https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_veyron/extra-files/boot/extlinux/extlinux.conf#L13
  23. @hexdump I didn't touch the bootloader, it is the original from the TV box. I only inserted the 72 bytes at the end of the 1st block (which was originally empty). It seems it is not possible to change the 1st block at all, even if you just modify the empty space. My guess is that when ROM is checking whether emmc has a valid BL it reads the whole 512 bytes (instead of just the length of BL) and does some CRC, or other validation, so even changing a single 00 byte will cause ROM to reject the bootloader. I even tried twice just to make sure I didn't make a mistake, I bricked both times. (Thankfully the Linux version of the AML USB burning tool is working very well). P.S.: yes it didn't start, I got that string from ROM (starting with "BL1" repeating in a loop.
  24. @pista- this is interesting - to me it looks like this in theory should really work the way you did it ... so in result it did not even start to boot then in this case? which boot blocks are you using - the ones i built or built them yourself?
  25. I tested in terminal mode ,'$ sudo systemctl set-default multi-user" which has really good performance. Your cutting edge armbian can achieve PSX full 60fps speed in retroarch (however, in legacy, I use wrong parameter which seriously impact performance) and snes9x framerate improved. I really surprise it is faster than legacy in my case. Really great.