chinhhut

could you share the way to boot Armbian from your H96 max 4/64? I've tried to follow exactly the steps from the guide in this topic but unable to boot from SD card.
My box look like this photo below:

Good evening,
 
I have got Orange pi 5 board. MAC address of this board network interface `end1` changes every time I reboot the system. I tried adding entry in /boot/armbianEnv.txt, I tried specifying hwaddress in /etc/network/interfaces. Neither of those two options worked.

andy.yan@rock-chips.com start to patch the RK3566 boards
i think this board will be supported by kernel 6.1
give it a try!

Thank you for the tips @jock
 
 
I have 2 H96max+ RK3328 ∕ 4GB  tvboxes.
 
Armbian 22.08 - Debian Bullseye minimal - mainline kernel 5.18.10
 
BOX1 :  On internal eMMC
BOX2:   Boot Armbian from SDCARD  , Android on internal eMMC
 
Benchmark from terminal:
mbw 1000  
Box1 : RAM 667Mhz CPU @ 1,3GHz
AVG    Method: MEMCPY    Elapsed: 0.82118    MiB: 1000.00000    Copy: 1217.764 MiB/s
AVG    Method: DUMB    Elapsed: 0.88632    MiB: 1000.00000    Copy: 1128.263 MiB/s
AVG    Method: MCBLOCK    Elapsed: 0.27756    MiB: 1000.00000    Copy: 3602.800 MiB/s
 
Box2 : RAM 333Mhz (Android uboot) CPU @ 1,3GHz
AVG    Method: MEMCPY    Elapsed: 1.51033    MiB: 1000.00000    Copy: 662.107 MiB/s
AVG    Method: DUMB    Elapsed: 1.62614    MiB: 1000.00000    Copy: 614.955 MiB/s
AVG    Method: MCBLOCK    Elapsed: 0.54709    MiB: 1000.00000    Copy: 1827.854 MiB/s
 
To boot from sdcard when Android on internal storage.
1. Flash Armbian on sdcard
2. Download Multitool.img 
3. Mount multitool.img on linuxpc or flash to another sdcard.
4. Copy  trustos.img and uboot.img from bsp folder to a folder on linuxpc,
5 . DD trustos.img and uboot.img to sdcard Armbian from linuxpc
 
sudo dd if=uboot.img of=/dev/SDCARD seek=16384 conv=fsync sudo dd if=trustos.img of=/dev/SDCARD seek=24576 conv=fsync  
 
 

Ubuntu 22.04 LTS rk3318-box is up and running nicely with working Docker and HA supervised looks working OK.
Up time is only some hours after install but the prereleases was also working stable so hopefully it shall doing the same.
 
Great thank devs for making it happening !!!

@fabiobassa Yes. I'm thinking about the defective emmc issue because I have several 3318 boxes and 1 box get this kernel panic issue, an other box get crashed after several hours running, other ones work well over time. 

@chinhhut
home assistant is a great project but at the same time is very hard disk intensive and resource eating. In special mode if you even have motion plug-in or other pugins that extensively use the hard disk and/or internal emmc
And it also coul be a defective emmc since many chinese tvboxes are badly assembled with faulty components

@chinhhut Ah ok, an error during shutdown... well I never experienced such issue, may be an error in the kernel or in the trust OS which is leading some spurious interrupt after secondary cores are brought down... I'm not able to recognize anything specific from that crash dump, but I may suggest you do add "panic=10" in the kernel command line: this way, when a kernel panic happens, the kernel may still try to reboot after 10 seconds so you don't get stuck.

No idea. From the "screen shot" (literally :D) it seems to happen right during startup or does it happen during regular runtime too?

@chinhhut
 
What services/app have installed?
Did kernel crashed before new installation or crashes even with unloaded system ?
As @jockexplained me, no user space applications should ever freeze/panic the kernel , unless drivers are involved.
And if kernel crashes I am afraid you Will not have any log either

If the kernel crashes then you have no other way than attach a serial adapter to the board UART to log continously, in the hope the kernel says something before the freeze happens.

@fabiobassa @jock I've followed your guide and got success. Thank you so much.
root@mybox:~/rkdeveloptool# ls 99-rk-rockusb.rules Makefile.in RKComm.h RKImage.h RKScan.h cfg configure.ac main.cpp CMakeLists.txt Property.hpp RKComm.o RKImage.o RKScan.o config.h.in crc.cpp main.o DefineHeader.h RKBoot.cpp RKDevice.cpp RKLog.cpp Readme.txt config.ini crc.o parameter_gpt.txt Endian.h RKBoot.h RKDevice.h RKLog.h aclocal.m4 config.log gpt.h rkdeveloptool Makefile RKBoot.o RKDevice.o RKLog.o autom4te.cache config.status license.txt Makefile.am RKComm.cpp RKImage.cpp RKScan.cpp boot_merger.h configure log root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Loader root@mybox:~/rkdeveloptool# ./rkdeveloptool rd 3 Reset Device OK. root@mybox:~/rkdeveloptool# ./rkdeveloptool db MiniLoaderAll.bin Opening loader failed, exiting download boot! root@mybox:~/rkdeveloptool# ./rkdeveloptool db /root/MiniLoaderAll.bin Downloading bootloader succeeded. root@mybox:~/rkdeveloptool# ./rkdeveloptool wl 0X0 /root/Armbian_21.11.0-trunk_Rk3318-box_bullseye_edge_5.14.14_minimal.img Write LBA from file (100%) root@mybox:~/rkdeveloptool# ./rkdeveloptool ---------------------Tool Usage --------------------- Help: -h or --help Version: -v or --version ListDevice: ld DownloadBoot: db <Loader> UpgradeLoader: ul <Loader> ReadLBA: rl <BeginSec> <SectorLen> <File> WriteLBA: wl <BeginSec> <File> WriteLBA: wlx <PartitionName> <File> WriteGPT: gpt <gpt partition table> WriteParameter: prm <parameter> PrintPartition: ppt EraseFlash: ef TestDevice: td ResetDevice: rd [subcode] ReadFlashID: rid ReadFlashInfo: rfi ReadChipInfo: rci ReadCapability: rcb PackBootLoader: pack UnpackBootLoader: unpack <boot loader> TagSPL: tagspl <tag> <U-Boot SPL> ------------------------------------------------------- root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Maskrom  

You should ask Android people then.
AFAIK Android images have some hardwired settings that make it work only on internal eMMC.
These settings should be changed to make it work, but don't ask me: never dig into.

@lucky62 : I have a board with a 3318 CPU and a 7-segment display, driven by a 6334 controller. I would like to ask if the openvfd driver you created will be good for this too? If so, am I still asking that your openvfd driver is already included in the jock's bullseye minimal image? I want to set up and control this display.

I found the correct method to fix the bug that the x96-max-plus(s905x3) gigabit ethernet  does not work:
Up to now, only HK1Box/vontar x3 is the only s905x3 TV box that can be used perfectly in armbian.  So I extracted the bootloader of hk1box and wrote it into x96-max-plus, and it worked.
This method is very simple, so it is recommended to everyone in need.
 
Step 1:  upload three dtbs into /boot/dtb/amlogic :
    meson-sm1-x96-max-plus-100m.dtb
    meson-sm1-x96-max-plus.dtb
    meson-sm1-hk1box-vontar-x3.dtb  (Similar to meson-sm1-x96-max-plus.dtb, only the modal name is changed)
 
Step 2:  modify /boot/uEnv.txt, replace dtb with meson-sm1-x96-max-plus-100m.dtb,  restart the Armbian system
 
Step 3:  upload hk1box-bootloader.img to /tmp
 
Step 4:  Run these commands under the shell:
dd if=/tmp/hk1box-bootloader.img of=/dev/mmcblk2 bs=1 count=442
dd if=/tmp/hk1box-bootloader.img of=/dev/mmcblk2 bs=512 skip=1 seek=1
sync
reboot
 
Step 5:  modify /boot/uEnv.txt, replace dtb with meson-sm1-x96-max-plus.dtb, and restart again.
 
 
meson-sm1-x96-max-plus.dtb meson-sm1-x96-max-plus.dts meson-sm1-hk1box-vontar-x3.dtb meson-sm1-hk1box-vontar-x3.dts hk1box-bootloader.img.xz meson-sm1-x96-max-plus-100m.dtb meson-sm1-x96-max-plus-100m.dts
x96maxplus-orig-bootloader.img.xz

Officially no. Too many hardware is seeking for very low time and expertise.
 

Example of first start
https://github.com/armbian/build/commit/3c4b69650e9f98edbf7f0a934add1dd19eb14772
Yes, it might looks complicated, but we are working on to improve the procedure. That is generally more useful for us.
 
 
Documentation - start there first:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
https://docs.armbian.com/Process_Contribute/
... and do small steps.
 

That kernel is shipped with the chip, while path to modern kernel is long, hard and expensive:
https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one
 
 
Armbian framework help yes, while for hardware related features - we can't finance hardware vendor business.

Update version 20211124 with legacy kernel.
 
 
p.s. Now I am testing a new image with a 5.16.rc2 kernel, in which HDMI and USB work. After all checks are completed, new versions of images with a new kernel will be available. 

@Elmojo
I know is not fine answer to a question with another question but in this case
 
comes very natural ask  : why did you modded it ??? Just for fun ? You didn't have a defined purpose in trying linux ?

Anyway, just to answer , in my personal study case I have done on it:
voip pbx ( asterisk)
network nas
network firewall
pihole dns firewall
openvpv, wireguard and tinc vpn
home assistant
volumio
special ip cam monitoring and data acquisition

and I guess I could experiment more..... if only I would study more potential applications

@callegar Thanks for spotting it out.
Actually it is my fault the package installs things in /usr/local/bin.
I will change that to install in /usr/sbin which is probably more appropriate
 
@chinhhut It could work, but it couldn't
The problem is shrinking the partition, you don't just need to reduce the partition size, you also need to shrink the filesystem appropriately otherwise you lose data and possibly the partition does not get mounted when restored.
Enlarging the partition (and the filesystem) is easy and almost cheap, shrinking can be painful. But you can try indeed! (And maybe realize that losing some time to restore the wholly 64Gb eMMC is better than a headache )

@chinhhut Actually armbian provides a way to introduce user-level patch files which can modify the behaviour of the installed system.
It means that you can, to some extent, launch sudo ./compile.sh and finally produce an image customized for your needs.
 
Armbian documentation will help you further.

First page, github repository has always been public

I will study more how to patch some additional files but could you share the source code to build RK3318 image?
Thank you so much for your support.

Personally, we still hope our hero @jock will take a look on rk3566 soon in near future. For now, I feel happy with my 3318 box.

@chinhhut @curse
The backup made by multitool (and rkdeveloptool) is per nature a full backup of all the physical eMMC sectors. It has no knowledge of the abstract structures like filesystem and files.
The compression gives back a more manageable file which is not the entire size of the eMMC, but up to a few gigabytes, depending on how much data is stored on the eMMC and how much compressible it is.
 
Indeed if you decompress it, you get the whole size of the eMMC, it is expected and it is advisable too. If it is not so, it means the backup process didn't went right.
 
Now should be clear there is a problem about the "blank" part: how we can know if a part is "blank" and not, for example, a piece of a file which just contains a long string of 0x00 bytes? This is crucial: if you say that you skip those parts which are, supposedly, blank, you may (and probably will) fail to restore files that contains long string of 0x00 bytes. You won't get 0x00s in those places, but you will instead find there the contents of the unwritten eMMC sectors.
 
So a full restore of all sectors is essential to restore the exact previous condition when doing a full backup.
 
One helpful thing that may be helpful here is to use the native page erase feature of eMMCs, which is the thing blkdiscard program do and is at the bottom of the famous TRIM feature: flash memories are divided into "pages", ranging from several kilobytes to few megabytes usually.
Erasing those pages using the discard command is very fast, much faster than zero-filling. You can erase all the pages of a whole eMMC in a few seconds, while zero-filling all the pages would require dozens of minutes.
 
Doing an erase with blkdiscard and then restoring the backup skipping the blank parts now becomes sensible!
There is an issue though: discarding pages does not fill them with 0x00 bytes, but with 0xff bytes, so the real blank parts now are not those which contains string of 0x00s but those which contains strings of 0xff bytes. Those may or may be not so common. Surely they are common in non-programmed sectors, but results may vary.
 
As a conclusion: restoring the whole count of eMMC sectors, despite being slower, is surely the simplest and most reliable way!

I noticed the same when I was trying to restore my backup. It got stuck at around 20-25 percent and I thought it might work better if I uncompress it first.
Oups, I have a 64GB eMMC, and the SD card I had at the time was only 16 or 32 GB. 
The backup is a raw disk image of the eMMC, and it will always be the same size as the eMMC until it's compressed, and "removing the blank data" is part of the compression process.