hexdump

  • Posts

    398
  • Joined

  • Last visited

Reputation Activity

  1. Like
    hexdump got a reaction from jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @jock - i can confirm that those old mx10 boxes were rk3328 and they were the only ones i saw, which had a proper cpu voltage control ... i once had one of those some time ago
     
    @Matteo Venturi - i think there are at least two versions of this box: an older rk3328 one which should work very nice out of the box (i have one of those) and a newer rk3318 one which might have a few surprises in it resulting in it no longer working that easily
     
    best wishes and good luck - hexdump
  2. Like
    hexdump got a reaction from Willy Moto in CSC Armbian for RK3318/RK3328 TV box boards   
    @elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    best wishes and good luck - hexdump
  3. Like
    hexdump got a reaction from Dan MacDonald in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  4. Like
    hexdump got a reaction from Willy Moto in qplus as headless midi synthesizer   
    @fizban - for me those cheap pcm2704 adapters usually gave much better latency than the other cheap usb audio adapters: https://github.com/hexdump0815/sonaremin/blob/master/images/pcm2704-01.jpg
     
    maybe have a look at sfizz as a sampler - it allows to use sfz files (much better than simple sound fonts) of which there are quite a few amazing ones around on the net (quite a few on pianobook for instance):
    https://github.com/sfztools/sfizz/
    https://github.com/hexdump0815/sfizz-arm-build (my notes on building it on arm)
     
    if you want to go a bit furher, you can even run a full modular synth with around 2k avaiable modules (vcvrack) on your qplus - i did builds for h6 tv boxes for an older version - for instance here: https://github.com/hexdump0815/sonaremin/releases/tag/v1.1.6_8 but not yet on the latest improved version https://github.com/hexdump0815/sonaremin-ng ... but for vcvrack you'll have to add a fan to your box as it otherwise will get too hot and throttle the cpu
     
    good luck and best wishes - hexdump
  5. Like
    hexdump got a reaction from vilodeid in OrangePi Zero2 - Allwinner H616   
    @vilodeid - in case you really want to play around with panfrost on h616, then maybe have a look at this https://oftc.irclog.whitequark.org/linux-sunxi/2021-05-27#29961750 and the irc logs from the following days ... a lot to read and not really easy stuff, but i think this the most detailed information which is there so far regarding this topic
     
    happy reading and best wishes - hexdump
  6. Like
    hexdump got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    @jock - do you have this extracted ddrbin somewhere in your repos already? i was not able to find it yet ...
  7. Like
    hexdump reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    Nope, not yet, I'm a bit busy with rk3288 at the moment, but here you go: ddrbin_v1.16.bin
  8. Like
    hexdump got a reaction from Willy Moto in Allwinner H6   
    ... and be aware that there are quite a few fake tv boxes around (very popular for q+ too) which are sold as 4gb (and in android they even hacked it to look like this), but only have 2gb of memory built in ... so it can be that the box simply only has 2gb in the end ... maybe do an "apt-get install memtester" followed by "memtester 2500M" on the box with your 3072M setting - if it runs through stable you seem to really have 3gb, if it hangs or crashes doing so you most probably only have 2gb
     
    good luck and best wishes - hexdump
  9. Like
    hexdump got a reaction from stonetv in Armbian on B860AV2.1-M with S905L3-B   
    looks like the s905l3 is another of those amlogic socs where they did reduce the hw even further to bring down the price - for the s905l2 this one helped for me: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av8/dtb/meson-gxl-s905l2-x7-5g.dts but your trace looks different ... good luck for finding out what they changed this time
     
    p.s.: it looks like the above change is needed there too, but looks like they even crippled the vpu and/or hdmi hw as well ...
  10. Like
    hexdump got a reaction from jock in Cards on the table: Which boxes have working WiFi?   
    the ssv6x5x chips are not supported in mainline or with anything else than the meanwhile quite dated rockchip legacy tree and as the existing sources and docs for them are so bad (and i guess the hardware design as well) they most probably never will be supported in mainline.
     
    mxq boxes can have everything in them: they exist with allwinner, amlogic and rockchip socs in them combined with a large variety of wifi chips. tv boxes can be fun to play with but never expect anything to be too well - you might win the lottery and get a really good one with supported wifi,good case, power supply and heat sink etc. and you can end up on the other end where the 4gb/32gb emmc box you bought in reality is just a1gb/8gb nand box with unsupported wifi there the first components fall off the board after a few weeks. i think the second option get more and more likely nowadays
     
    enjoy those toys if you run across them, but better do not trust in or rely on them ...
     
    best wishes - hexdump
  11. Like
    hexdump reacted to lanefu in Armbian the Virtual Machine   
    quick update.. armbian now produces a qcow2 image for the virtual-qemu build...

    I installed virgl but still working on a script to launch...  
  12. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @Dragao - dying emmc is something which happens from time to time with tv boxes - i had it on an amlogic box and i think @jock and @fabiobassa can sing a song about this topic too ... i think tv boxes are sometimes assembled from very low quality components to push prices down ...
  13. Like
    hexdump got a reaction from Jeremiah Cornelius in Release Announcement: TWO New, Community Unofficial Armbian MAINLINE Desktop Images for Khadas VIM3 Pro   
    @Jeremiah Cornelius - for your lightdm issue, maybe give the slick greeter for lightdm a try - it fixed my problems with non working lightdm on 32bit arm - might be worth a try
     
    best wishes and good luck - hexdump
  14. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    best wishes and good luck - hexdump
  15. Like
    hexdump got a reaction from ArkhanLK in CSC Armbian for RK322X TV Boxes   
    @jock - just in case: the slick greeter is also working well on armhf
  16. Like
    hexdump got a reaction from jock in CSC Armbian for RK322X TV Boxes   
    @jock - just in case: the slick greeter is also working well on armhf
  17. Like
    hexdump got a reaction from lanefu in Armbian the Virtual Machine   
    @lanefu - as you mentioned the m1 mac: there is a very nice brew package around, which gives you a qemu there which even sends opengl via virgl and angle to the m1 gpu - not the fastest in the world, but better and more cpu saving than software rendering - https://github.com/knazarov/homebrew-qemu-virgl
  18. Like
    hexdump got a reaction from SteeMan in A really dumb question Amlogic Vs RockChip vs Allwinner   
    @jock - i think amlogic (the company) still is not very good regarding open source, but at least linux mainline is quite useable on their chips
     
    the emmc clk pin trick works for amlogic too (if one finds it ) and wiping the emmc results in a boot from sd card ... the main problem is that the legacy u-boot reads its dtb from a later partition on the emmc and fails if it cannot find it - this is a problem if one for instance fdisk's and mkfs the emmc: the u-boot itself can still be intact, but it is bricked as it can no longer find its dtb (this is why the balbes150 amlogic images always kept 700mb and later more of the emmc in place when installing onto emmc to avoid overwriting this sensitive information) ... putting a mainline u-boot on amlogic boxes is possible but due to the complex boot structure and the required fitting blobs way more complicated than on rockchip and allwinner ... in summary: if amlogic then best is a properly supported sbc (odroid etc.) - unsupported stuff like tv boxes can result in quite a bit of extra work and unwanted surprises with those socs
  19. Like
    hexdump reacted to tripole in Chainloaded uboot images for amlogic   
    @hexdump
     
    Thank you for your work on these chain loaders. It has enabled me to do something I have wanted for a long time.
     
    I have your g12a-u-boot.bin (renamed to u-boot.ext) running on my Ugoos AM6 plus, in a multi-os boot setup, with all OSes installed on the SD (utilizing the vendor boot for the all boot stages except the last, which is in u-boot.ext). Currently, I can boot into Armbian Meson64 (Hirsute flavor, built in QEMU based on the rootfs file tree), Manjaro ARM (for VIM3/Ugoos, copied from distro image), and a Armbian Buster mini as rescue (also from QEMU/rootfs).
     
    By writing the entries in extlinux.conf according to the correct menu syntax (inferred from e.g. pxe_utils.c in u-boot source, see below) one can select which kernel+initrd+dtb to load, and which root file system to mount. (One has to be quick at the second prompt to make the OS selection. This prompt appears at the sysboot stage, after u-boot autoload has timed out. Perhaps the sysboot timeout can be extended a bit? Edit: The TIMEOUT keyword does not seem to take effect.)
     
    On all the OSes I have kept their original /boot dir and then added a new mount point /boot_FAT32 where the first FAT32 partition is located (with extlinux.conf, kernels+initrds+dtbs, and u-boot.ext), and updated the local /etc/fstab accordingly. Then it is simple to propagate the changes made to /boot under a running OS also to the boot partition. The SD layout/geometry is essentially: From the first available sector (2048, no gap needed) and 300M onwards; the kernel+initrd+dtbs and extlinux.conf stuff on a FAT32 partition. The follows, after perhaps a common swap partition, a number of ext4 partitions with the different OSes.
     
    Here is what the extlinux.conf can look like
     
     
    P.S. I know it is hard to compile these loaders correctly: From u-boot-amlogic (custodian) have have managed to compile, starting with different defconfigs, chain loaders that boot but with; no (HDMI) screen, green screen (several flavors), and indeed, purple-pinkish screen, but not one single working properly. Doh.
  20. Like
    hexdump reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    ­DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware.

    Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).

    Thank you!
     
    This thread is to give stable and mature long-term range support to rk3318/rk3328 found in many tv boxes in Armbian project as Community Supported Configuration (CSC).
    The current work is in early stages, it may or may not work for you; if and when it will be considered mature enough, it will be hopefully merged into Armbian master, but in the meantime it lives on my personal fork on github -> here <-
     
    Important notes: is just a personal opinion, but apparently widely supported, that rk3318 chip is not an official rockchip part. They probably are scrap rk3328 parts which have not passed conformance tests but are sold anyway to tv boxes manufacturers. They don’t reach the same operating frequency of the rk3328, have much higher leakage currents (and thus higher temperatures) and often the boards they are installed on are low quality with low quality components, in fact a very very common issue is the eMMC failure due to bad parts and bad soldering. So said, I personally suggest not to buy any rk3318 tv box, but instead find a properly supported SBC (Single Board Computer) if you need a reliable product. In the unfortunate case you already have such product, this thread may help you have some fun with them.
     
    What works:
        • Works on RK3318 and RK3328 TV boxes with DDR3 memories
        • Mainline u-boot
        • Mainline ATF provided as Trusted Execution Environment
        • All 4 cores are working
        • Ethernet
        • Serial UART (configured at stock 1.5Mbps)
        • Thermals and frequency scaling
        • OTG USB 2.0 port (also as boot device!)
        • EHCI/OHCI USB 2.0 ports
        • MMC subsystem (including , SD and sdio devices)
        • Hardware video acceleration (fully supported via RKMPP on legacy kernel, support via hantro and rkvdec kernel driver on mainline)
        • Various WIFI over SDIO are supported
        • Full acceleration on legacy kernel and mainline kernel. Mainline has lima driver compiled in but X11 is albeit slow - you are still free to compile and install mali kernel driver on mainline yourself.
        • U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal ; you can install u-boot (and the whole system) in the internal and u-boot will always check for images on external sdcard/USB first.
     
    Unbrick:
    Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the clock pin on the PCB. Here there is the procedure (for rk322x, but on rk3318 is the same), but you can also google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver.

    There are however some unfortunate cases where shorting the clock pin is difficult or impossibile, like BGA chips with no exposed pins. In those cases pay double attention when burning something on the internal flash memory and always test first the image booting from the sdcard to be sure it works before burning anything in internal flash.
    This is a list of posts where forum users have been able to spot the eMMC clock pin to trigger the maskrom mode:
    Ninkbox N1 Max RK3318 by @enigmasphinx  
    Partecipation and debugging:
    If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
    In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
     
    upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port; a link to the original firmware (you can do a full backup with the Multitool); some photos of both sides of the board. Some details of the eMMC, DDR and Wifi chips are also useful  
    Multimedia:
    If you need multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post
     
    Installation (via SD card):
     
    Building:
    You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to /TVB/ boards and select "rk3318-box" from the list.
       
    Development images:
    Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.10.68 - Download from here - Build date: 2021-09-24 Armbian 21.11 - Ubuntu Hirsute desktop [xfce] - mainline kernel 5.10.68 - Download from here - Build date: 2021-09-24 Armbian 21.05 - Debian Buster minimal - legacy kernel 4.4.213 - Download from here - Build date: 2021-04-16  
    Multitool:
    Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
    Quick installation instructions on eMMC:
    Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card FAT partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
    Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
    Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in , the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
     
    Quick installation instructions to boot from SD Card:
    If you are already running Armbian from eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal ; Congratulations, Armbian is running from SD Card!  
    A note about boot device order:
    With Armbian also comes mainline U-boot. If you install Armbian, the bootloader will look for valid bootable images in this order:
    External SD Card External USB Stick in OTG Port Internal  
    Critics, suggestions and contributions are welcome!
     
    Credits:
    @fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk3318 into armbian would not have begun without his support! @hexdump for his precious support in early testing, ideas and suggestions
    @MX10.AC2Nfor his patience in testing mxq-rk3328-d4 board support
    All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
     
     
  21. Like
    hexdump reacted to XFer012 in OrangePi Zero2 - Allwinner H616   
    Ok, so let's see the steps I followed.
     
    1. Installed Armbian Unstable for OrangePi Zero2:
    https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
     
    2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
    ethtool -s eth0 speed 100 duplex full autoneg off
     
    3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
    https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
     
    4. Extracted the various parts and fixed the symlinks:
    Image -> Image-5.11.0-rc1-stb-616+
    uInitrd -> uInitrd-5.11.0-rc1-stb-616+
    dtb -> dtb-5.11.0-rc1-stb-616+
     
    5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
     
    6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
    [ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  
  22. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them
     
    good luck - hexdump
  23. Like
    hexdump got a reaction from gounthar in OrangePi Zero2 - Allwinner H616   
    @XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices
  24. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel
     
    i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work
     
    all that is not a perfect solution, but maybe its helpful for you on your way
     
    good luck and best wishes - hexdump
  25. Like
    hexdump got a reaction from gounthar in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs