hexdump

Thanks Hexdump. You are right. I found this http://warped.inet2.org/pkg/minimyth2-garchive/u-boot-h616-v2024.01-2024.01/. Looks like the latest patches for u-boot and http://warped.inet2.org/pkg/minimyth2-garchive/linux-6.7.4/ kernel patches.

@pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
 
Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
 
Some notes:
THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
ddrbin-switch-freq.sh

I managed to fix the device
I downloaded u-boot.bin from that thread
Then I ran it from uart using 2 commands:
fatload mmc 0 0x01000000 u-boot.bin
go 0x01000000
 
With this u-boot version, the system booted up fine.
 
After that, I tried to overwrite the corrupted u-boot using dd command. I failed but actually, that broke uboot on emmc which allowed the device to enter usb download mode. From that, I was able to write original ROM using amlogic burning tool

Hi all!
Maybe this will be useful to someone.
I had a TVbox H96Max H2 with firmware RK3328-BOX_7.1.2_20180620.2051_H96MAX
I tried flashing other android firmware of different versions but without success.
I tried to install many versions of Armbian in different ways  but it did not start from the SD card and SD+USB.
The Multitool also not start. I tried launching with different .dtb
This is the only method that worked for me: I re-recorded the U-boot using Windows 10 and RKDevTool GUI
I download  U-boot from here:
https://github.com/hexdump0815/u-boot-misc/blob/master/misc.rk3328-no-sd-boot/rockchip-u-boot/u-boot-image-for-emmc-h96max-rk3328.img.gz
Then I recorded to the SD card using the Multitool from straight from this thread
https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/
I used Linux Mint and Etcher GUI to record Multitool on my SD card.
I added this image Armbian_23.8.1_Rk3318-box_bookworm_current_6.1.50 to the img folder of the SD card
I only need a server.
The Multitool loaded from the SD perfectly but the Armbian installation is 98% frozen. After some time I rebooted the TVbox... and complete success. Armbian server works well.
I extracted .dts from the android firmware. I recorded several UART logs.
Once upon a time I soldered wires and connected a UART converter and recorded logs, but not always, unfortunately.
I want to say thank you to all the developers and enthusiasts of this project!



armbian.log android.log android.dts android.dtb

@n3o  As a moderator of these forums, I have been watching your postings.  You are abusing these forums and the people that contribute to them.  (Everyone, especially @RaptorSDS and @jock have been very willing to invest a lot of time to help you)   However, repeatedly you have been given specific information that you ignore, been given advise that you ignore and then you come back with more and more questions.  There are very limited people resources working on Armbian (and even less with TV boxes).  You alone are consuming way more developer time than any one individual has the right to receive.  This is open source, and therefore users are needed to contribute as much as they consume in resources from the community in order for this to work.  This is not a school where you can come to be taught how everything works, demanding the attention of everyone else to teach you. 
 
Your latest questions are now venturing into very deep and difficult areas of code (none of which is expected to work on these TV boxes as has been mentioned to you).  If you want to continue down the path you are going, you first need to become an expert at these topics on known working platforms, then you can try to apply that expertise on TV boxes.  You may not realize it, but the questions you are asking, are essentially asking for weeks if not months of developer help to get working, if it is at all possible.
 

@stut - here i wrote down quite a bit of information about how to build mainline u-boot for amlogic s905x/w devices - see: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxl - you might try the ones i built (see the july 18 2020 releases of that github repo) - gunzip all the files with boot-amlogic_gxl_*.gz and then dd them to an sd card and try to boot them one by one with serial console and a hdmi monitor connected (some have serial console and some hdmi) - if you are lucky one of them maybe gives you a working mainline u-boot you can boot from sd card
 
good luck and best wishes - hexdump

@hexdump it seems that you were absolutely right regarding the issue here! After lowering the max CPU speed from 1900 to 1800, I've done more than 100 benchmarks without facing Illegal instruction
 
Thank you very, very much!

here are some images of the board ... i think i just fried a serial to usb converter while testing the three copper pins on the back side a few minutes ago ... in general: the box is booting perfectly fine, its just that it hangs / shuts down or whatever exactly one minute after the box was powered up for any kind of image i try (libreelec, armbian) ... i also tried to extract the trust.img via rkdeveloptool from emmc (rkdeveloptool rl 0x4000 0x2000 rl-0x4000-0x2000.out) and wrote it to the proper position on the sd card (dd if=rl-0x4000-0x2000.out of=/dev/sdx bs=512 seek=12288) but it did not make any difference in the end ...
 
update: the offset for writing it to the sd card was wrong above - here are the proper commands and now the box is working fine
rkdeveloptool rl 0x4000 0x2000 rl-0x4000-0x2000.out
dd if=rl-0x4000-0x2000.out of=/dev/sdx bs=512 seek=24576
 
but if the board looks familiar to you and you know where the serial port connectors are, i would still be interested to know that ...
 

@jock - i think at least on newer rk3229 boxes (with a newer boot loader) you seem to be able to boot from sd card without having to erase the emmc content. i just did an experiment on my r394k rk3229 box: i took your ubuntu image and later took the root fs from it, then dd'ed the first 16mb (boot stuff) from a working libreelec build (https://github.com/knaerzche/LibreELEC.tv/releases/tag/RK322x-le92-0bca75f and https://forum.libreelec.tv/thread/21117-unoffical-le-9-2-images-for-rk3229-rk3228/?pageNo=1) to a fresh sd card, created a partition on it starting at sector 32768 (to not overwrite the boot stuff), made that active in fdisk (not sure if this is really required for u-boot to search for its extlinux there), created an ext4 fs on it, rsynced your image root fs to it, created an /extlinux/extlinux.conf with the following content:
TIMEOUT 30 DEFAULT rk3229 MENU TITLE rk3229 boot options LABEL rk3229 MENU LABEL rk3229 kernel LINUX ../boot/vmlinuz-4.4.189-rk322x FDT ../boot/dtb-4.4.189-rk322x/rk3229-r329q.dtb INITRD ../boot/initrd.img-4.4.189-rk322x APPEND earlyprintk root=UUID=<put-your-root-fs-uuid-here> console=ttyS2,115200n8 console=tty0 rootwait rootfstype=ext4 consoleblank=0 loglevel=8 adjusted the root fs uuid accordingly, put the sd card into the box and powered it on ... and it booted fine from the sd card although the android on the internal emmc is still there. i noticed something similar on a rk3318 box too: the rockchip bootloader initial stages seem to load a u-boot.img from the sd card if there is one there (i think it was at sector 16384 offset) and i think this is how it works here: emmc boot loader starts with its first stage and sees that there is a u-boot.img stage on the sd-card and starts this one and from there it goes on.
 
with my box the system boots to a login prompt and then i think tries to start x11 - there it seems to hang and the keyboard got dead (num lock which is working fine during boot does not respond anymore - i tried all usb ports etc., mouse is still fine though, i.e. it got power still and its led was on) so that i cannot switch back to the console. i tried to disable the x11 startup on the root fs of the image but failed - do you know a quick way to disable it directly on the filesystem? do you have an idea why the system locks up? sadly this box does not seem to have serial console connectors
 
is your kernel supposed to work on rk3228a too? if yes, then i might give it a try on my mk809iv as well ...
 
a lot of thanks for your work on getting armbian working on those boxes and best wishes - hexdump

@hartraft - there are two kernel options for mglru: CONFIG_LRU_GEN=y and CONFIG_LRU_GEN_ENABLED=y - the first is to have mglru built into the kernel and the second is to have it enabled by default - if they are not in your kernel config it might be required to rebuild the kernel with them (or at least the first) enabled

After a fix committed this past week, these builds now work on all the amlogic based boxes I have:
TX3mini (s905w)
X96mini (s905w)
H96MaxX2 (s905x2)
TX3 (s905x3)

Armbian now has a community supported build target for amlogic TV Boxes (aml-s9xx-box).  You can now build your own builds directly with the Armbian build system.
 
This is now an opportunity for members of the community to move the support for amlogic TV boxes forward within the Armbian framework.  If you are not familiar with the Armbian build system check out the Armbian developer documentation.  If you have idea on how you would like to see things evolve/change please use this forum to share your thoughts and ideas and submit PRs for any code changes you would like to see.
 
I am currently testing this code against the four different amlogic based boxes I own, but would appreciate others testing as well.  Once I have completed my testing, I will be updating the FAQ amlogic install instructions with this information.

Finally! On my personal testing on 5.19.x never had any issue with both armhf and arm64 architectures

Multi-Gen LRU has just landed. In 6.1.0, the support can therefore be used out-of-the-box.

Thanks.
 
Now we may consider switching all boards to MGLRU on 6.1 😀

@rzu- i did not try the images from waprme's minimyth2, but i'm using the patches for both the h6 and h616 to build my own images (not armbian) and they are working very well so far - i would say its the most complete patch collection for h616 right now
 
best wishes and good luck - hexdump

Yeah, I'm working on it. Will keep you posted. Thanks.

UPDATE!!
 
Hello, I'm pleased to announce that rk3318 CSC configuration has been accepted into mainline kernel!.
This means that next Armbian release (probably August) will provide regular kernel upgrades offered by Armbian ecosystem via normal apt upgrade command.
Until then, please stay stick to the usual manual upgrade!
 
But there is something more: new update for the rk3318/rk3328 images!
Most important changes:
Kernel upgraded to version v5.18.6 Memory clock set to 667 MHz (was 333 MHz), providing a nice boost in general, desktop and GPU performance; despite this works fine on my board I always warn you to test images first via sdcard Introduces MGLRU patches from @yuzhaogoogle (you can read about here and search google for more details), which should provide much snappier experience especially on low-memory devices You can find the images and deb packages for upgrades browsing the directory pointed on first page as usual.
 
You can visit the Armbian MGLRU topic, if you have questions about the features or kernel issues (like crash dumps which involve kswapd, for example)
 
 

@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump

@hexdumppointed me to this discussion -- thank you for all the testing, much appreciated!
 
If you have MGLRU related questions, please feel free to shoot me emails.
 
The following option occasionally causes problems, so please set it to zero. The analyses from Ubuntu, Debian and a few others I'm too lazy to quote
$ cat /proc/sys/vm/watermark_boost_factor 0  
I'll submit a fix later today and hopefully it'll be in v5.20.

@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump

@rzu- i did not try the images from waprme's minimyth2, but i'm using the patches for both the h6 and h616 to build my own images (not armbian) and they are working very well so far - i would say its the most complete patch collection for h616 right now
 
best wishes and good luck - hexdump

Thanks a lot, ended up that yesterday I tested kernel v5.18.0 on rk322x with the old version of the extra patch compiling the whole debian mesa packages ecosystem with success. The box was sporting just 1gb of ram, 512mb of zram swap space and 2gb of extra USB HDD swap file.
The conditions were absolutely heavy and unhealthy, but the whole packages rebuilding from sources finally completed without errors, even after extreme swapping and hours of compilation time. The system was always responsive to SSH shells, which is a great achievement by itself!
 
 

@jock - i already sent you a pm about this, but meanwhile i tested it to be working for me, so maybe its better to post it here as well in case others are interested too: i got a response from the mglru patch series author and a patch which seems to fix the problem on 32bit arm for me (tested on rk3288 with 2gb ram so far) - the patch can be found here: https://github.com/hexdump0815/kernel-extra-patches/blob/main/multi-gen-lru/v11/v11-15-extra-patch-from-author-with-armv7l-fix.diff
 
good luck and best wishes - hexdump

@hexdump Thanks a lot! I later checked out the patch series and in the description armhf architecture is effectively omitted, so probably is untested and not expected to work. Anyway I don't know how it could enter into mainline if it is allowed to compile on armhf but cause heavy issues: the kconfig file should at least be patched to allow compilation only on amd64 and arm64 architectures.
 
I hope they will provide fix and tests for armhf too - hopefully x86 32 bit too. Those 32 bit architectures are going to benefit a lot from this patch since most memory-constrained devices are 32 bit only.