hexdump

  • Content Count

    323
  • Joined

  • Last visited

Reputation Activity

  1. Like
    hexdump got a reaction from lanefu in CONFIG_RT_GROUP_SCHED=y harmuflull for real time applications   
    @Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ...
     
    best wishes and good luck - hexdump
  2. Like
    hexdump got a reaction from Seth in CSC Armbian for RK322X TV Boxes   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  3. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  4. Like
    hexdump reacted to jernej in OrangePi Zero2 - Allwinner H616   
    If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)
  5. Like
    hexdump reacted to jernej in OrangePi Zero2 - Allwinner H616   
    Good thing is that things are coming together slowly. There is a hack to make USB work and first part of display stack started to work (not usable yet).
  6. Like
    hexdump reacted to jock in Planned changes to the TV Box area   
    I'm always happy about tidying up things, and tv boxes section is still far from being ideal. Honestly I don't know if it is a wise idea to have a section "TV Boxes running Armbian" and I explain why: it could work well with serious and proper brand products, but if you mean to tidy up the forum against the chinese brands, well, we have to face the reality that cheap chinese tv boxes don't have any proper nomenclature. Often you get a recognizable pattern, sometimes you don't. This is especially true for the cheapest products and so things that have the same market name may have a different hardware, either "just" the wifi chip or a completely different board with another SoC. Anyway, trying is costless, so let's try it
     
    Personally I maintain the rk322x and rk3288-xt-q8l-v10 (xt-q8l-v10 is a rk3288 tv box board) CSC threads and so far I have to say I never had to ask a moderator to delete a post or ban a person. We never faced any major inconveniences with users, yet people has been very collaborative in some cases that we brought up hardware support remotely (esp8089 wifi support, for example) and very often people sends device trees to be analyzed. The rk322x thread has been a great source of fun
     
    IMHO they work well because:
    the subject is clear - since most of the problems are related to the hardware, bringing in many architectures in the same place will incredibly increase confusion. One architecture and its related kernels, that's more than enough. the first post covers the basics - though I have to say that preparing such pages to be simple and effective took a lot of time and effort - it is terribly useful for users. Most people read this and finds their way. Some don't read the first page, so you kindly redirect there, some skilled or unskilled people read the first page, don't get it and post. They get attention as long as they show to be collaborative. If they acts like childish leeches they will just get ignored. the thread is a linear history of what happened and when - except for the first page which is often updated with the "must read" infos, reading the last 2/3 pages of the thread are enough to get up to date stay within the armbian rules - it means that even if they are tv boxes, they fit and integrate into the armbian ecosystem as much as possible. For example: if FAT is not supported by armbian (yet it is, but that's an example ), don't use your own hacky thing to make a FAT partition but bring FAT support into armbian; if the board uses some firmware, don't put the firmware somewhere hidden but commit the firmware to armbian-firmware repository and fix the thing with a generic patch, and so on... It's harder, but it's better and brings much better cooperation at all levels and people will find the stable board/box images in the right place (the Download page), not elsewhere.  
    Getting back of the tv box club, I share my wonders about how it could be arranged - that's just an idea, it could be totally wrong...
    Along with the "Overview" and "General chat" sections, since there are just 3 major vendors they could be put as main tv box club sections.
    Overview is cool because it's a "what's new" overview page. I consult it often and finds it very useful to spot recent posts that may be interesting.
    General Chat is where newbie people will probably post, along with generic threads and posts asking for help. There I would put a pinned "FAQ" and "must read, forums rules" thread.
     
    The three vendors sections (Rockchip, AmLogic, Allwinner) will be less touched by newbies which don't even know what Rockchip/Allwinner/AmLogic are; people with just a tiny bit of experience instead would post vendor specific questions in the vendor sections.
    I would put the "CSC megathreads" in the vendor specific sections. People who wants to cooperate to support some chip of that vendor or talk about that vendor could freely do that in the vendor section; if interesting discussions arise (like happened in the recent past for S905X3), threads could be pinned or CSC support materializes for a tv box/board/architecture, there could be a pinned thread for that too.
    As an example, S905X3 tv boxes don't have CSC support, but may have a pinned thread (one pinned thread for one architecture) to let people discuss about it in one place, decent tv boxes (Beelink S922 ones just popped in my mind) may have a separate pinned thread if there is a CSC maintainer for that board if there is discussion or enough interest about.
     
  7. Like
    hexdump got a reaction from TRS-80 in Free and Libre Open Source SBC List Thread   
    i think you can run some allwinner socs (at least the h6) and some rockchip socs nearly blob free as they do the memory setup themself, have open source atf (and sometimes optee too) and u-boot. maybe a free usb wifi might be required as boards sometimes come with wifi requiring blobs. this way one might even be able to make a cheap h6 tv box into a blob free system
  8. Like
    hexdump got a reaction from TRS-80 in Free and Libre Open Source SBC List Thread   
    but those are fixed ip cores in the hardware and not loaded later - if you want to get rid of those i think you have no chance to get a useable system going at all ...
  9. Like
    hexdump got a reaction from Werner in RK3318 device (Magicsee N5 Nova 4g/64g) with dead NAND   
    @Lambert or some moderator: i think what is ment here is rk3318 and not rk3188 - it might be good to adjust the title ...
  10. Like
    hexdump got a reaction from guidol in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  11. Like
    hexdump got a reaction from sucotronic in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  12. Like
    hexdump got a reaction from TRS-80 in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  13. Like
    hexdump got a reaction from anbodearg in s905x3 board died, no led, no hdmi output   
    i think the best you can do is trying to connect a serial console to it - then you'll see for sure if it still gives signs of life from it or not and what you get then might help you to find possible options to recover it if recovery is still possible ... a dead emmc might result in the behaviour you describe: as the balbes images use the legacy u-boot on emmc on the box for booting on amlogic and a broken or dead emmc might result in nothing happening when turning on the box, but of course it can also be completely dead or just something trivially corrupted.
  14. Like
    hexdump got a reaction from NicoD in Since Tanix TX6 can boot from the SD card   
    allwinner h6 tv boxes usually do not have a voltage regulator for the cpu voltage and thus always run at full voltage even if the frequency is scaled down, so throttling is very inefficient here - in my experience they close to always need active cooling to deal with any serious load for a longer time at full cpu frequency ... i only have one board where i replaced the original heat sink with a much larger one and added fresh high quality thermal paste between it and the soc and that one can run without a fan if not in a case (i.e. good air flow) ... s905x3 is much cooler as its cores are done in a 12nm process vs. the 28nm process of the h6
  15. Like
    hexdump reacted to jock in CSC Armbian for RK322X TV Boxes   
    I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
    The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
    the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before) the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000 the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot u-boot finally loads the device tree and boots the kernel when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
    Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
     
    The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
    The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory the SoC ROM code reads the u-boot SPL that immediately follows the TPL u-boot SPL executes the OPTEE trustos u-boot SPL executes the main u-boot u-boot loads device tree and boots the kernel For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
     
    My guess is that the rk3318/rk3328 boot process is very much the same
     
  16. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    @jock @fabiobassa - to explain the difference between the addresses by the maskrom vs loader mode makes sense ... i think i did this hybrid setup with original initial boot blocks and mainline u-boot back then because i was thinking that this is the only way to get it working with the existing trust image ... where is it actually defined if trust images will be used or not - is it somewhere fused in the hw or is it just a matter of the initial boot blocks? if its just a matter of the boot blocks, then i should even be able to replace the entire boot with something adjusted self compiled maybe ... another reason i did it that way was that shortly before i did something similar for a rk3318 box for which there was no atf i could build myself (rk3328 one did not work) so i had to keep the original initial boot blocks there ...
     
    best wishes - hexdump
  17. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    you might have a look at this, but you are on your own then (no warranties or support from my side) - for me it worked to get my h96max h2 which cannot boot from sd card too working by installing an adjusted u-boot - https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot
  18. Like
    hexdump got a reaction from thanxx in Armbian for Amlogic S905X3   
    the legacy u-boot in those boxes is usually allocating away quite a bit of memory which you'll have to live with or your can try chainloading a mainline u-boot (which is what the u-boot.ext display hack is doing - on boxes where this is used there should be more memory available on average i guess)
     
    best wishes - hexdump
  19. Like
    hexdump reacted to Maker39 in CSC Armbian for RK322X TV Boxes   
    Since the changes from 10.04.2020 and the replacement of images on rk322x-box.
    Firmware replaced with new ones.
    LE_bootloader_Armbian_20.05.0-trunk_Rk322x-box_buster_current_5.5.16_minimal 2GB
    LE_bootloader_Armbian_20.05.0-trunk_Rk322x-box_buster_legacy_4.4.194_minimal 2GB
    LE_bootloader_Armbian_20.05.0-trunk_Rk322x-box_focal_legacy_4.4.194_desktop 4GB
    These are img from first post with Libreelec bootloader for boot without erase eMMC. Just insert a card and turn on power.
     
    Google Drive https://drive.google.com/open?id=1uoQvZUUFZyCWYFtatlTSJvJSSjUuJYLm
     
    26.06.2020
    Because at the moment, the firmware has lost its relevance. Deleted.
  20. Like
    hexdump got a reaction from Maker39 in CSC Armbian for RK322X TV Boxes   
    @Alessandro - you may try the following on a linux system, assuming your sdcard is in /dev/mysdcard (whichever device this might be in your case):
    "zcat working Librelec-xyz.img.gz | dd of=/dev/mysdcard bs=512 count=32768 status=progress"
    then use "fdisk /dev/mysdcard" to create a partition starting at sector 32768 (something like o, n, p, 1, 32768, enter, w, q - might be wrong - all off mind) and then dump the armbian image to it:
    "xzcat Armbian-xyz.img.xz | dd of=/dev/mysdcard bs=512 skip=8192 seek=32768 status=progress"
    and then try to boot that sd card - i think the armbian image uses an offset of 8192 sectors (@jock please correct me if i'm wrong here) - i never tried it this way, but in theory it should work and maybe be the fastest way to get libreelec boot and armbian rootfs combined
     
    good luck and best wishes - hexdump
  21. Like
    hexdump got a reaction from fabiobassa in Choice of TV box.   
    this is just a quick note that in my experience the amount of tv boxes with fake specs has grown quite a bit in the last months and that this is something to always have in mind when getting a box for a surprisingly cheap (i.e. quite a bit cheaper than usual or most of the other offerings) price - you might be lucky and it will be a bargain or you might hit one with fake specs. some examples i saw recently: a qplus 4g ram / 32g emmc ended up to be 2g ram and 16g nand, a h6 box sold as 4g ram / 32g emmc ended up as 2g ram / 16g emmc, a x96mini 2g ram / 16g emmc ended up at only 1g ram / 16g emmc, a r39 2g ram / 16g emmc with rockchip rk3229 ends up as 1g ram / 16g emmc and an allwinner h3 cpu and so on. the fake specs are not that easy to spot: in android they even fake the storage size shown in the storage settings and with a terminal installed even the "free" command tells you most of the time that the memory amount is proper. what usualy works for storage is "cat /proc/partitions" and watching for the device itself (for instance mmcblk0) - this also quickly shows you if its emmc (=mmcblk) or nand (=nand) and for memory "dmesg | grep -i mem" (do this immediately after booting android, otherwise the memory lines from the bootup might run out of the log buffer) - both of course called in a terminal app. booting one of balbes150's armbian images usually quickly shows you the real specs of the box too.
     
    good luck at not ending up with fake boxes and best wishes - hexdump
     
    p.s.: one thing to keep in mind is that allwinner h6 boxes always only can use 3g ram, even if they have 4g installed - this is a limitataion of the soc ...
  22. Like
    hexdump got a reaction from Nuno Cruz in Armbian for Amlogic S9xxx kernel 5.x   
    @Nuno Cruz - it is sometimes possible to extract some information from the original dtb and use it to adjust a mainline one, but its not easy and not always possible ...
  23. Like
    hexdump got a reaction from Nuno Cruz in Armbian for Amlogic S9xxx kernel 5.x   
    @Nuno Cruz - the original dtb is for android and most probably for another kernel version too, so there is no way to make it work without a lot of adaption work
  24. Like
    hexdump reacted to jock in CSC Armbian for RK322X TV Boxes   
    ahhh, right I remember that kernel config I had to disable the DMC devfreq config option because it was refusing to compile. Now it turned out that it was better to not have it.
    I'm going to publish new images with the dmc node disabled from the device tree, so there won't be any more issues.
  25. Like
    hexdump reacted to fabiobassa in CSC Armbian for RK322X TV Boxes   
    @hexdump

    thanks for replayng ;   you have a 3228 and not a 3229 , probabily a 3228b

    00000000  52 4b 23 82 the numbers 23 82 are 3228 in reverse mode
    so you must use trust os for 3228, the trust os for 3229 simply will not boot the board but this you already knew

    regarding the changing in code in kernel I did the following ( but no changes in code, maybe in make config ) : 

    in my long post linux on 3229  I used too the kernel 4.4.189 and it worked fine. I booted in 4.4.189 and take the config.gz and then recompile 4.4.194 with that same .config and it worked with SAME dtb .

    last info : I am pretty sure you have uart debug. At very early booting ( power on) what ddr it says ?

    ddr3 or ddr2 ? because ddr2 on 3228 HAVEN'T dmc ( ddr frequency scaling) so they will run at the speed that uboot set , probabily at 333 mhz ( all this infos thanks to @knaerzche that explained in his work on libreelec ).

    If you have ddr2 you must DISABLE dmc node in dtb


    boards with 3228b and ddr2..... well.... they are a bit slower than others


    EDIT:

    i realized the different behaviour from kernel 4.4.194 to 4.4.189

    in @jock config many thing are compiled as modules so then you must insert right modules under /lib/modules

    in 4.4.189 compilation many things are compiled IN kernel so they work  out of box, but yet you should check if have ddr2 or ddr3