Povl H. Pedersen

Hi, I am using the Debian from below location. Running Containerized Home Assistant on my H96Max X3. After I started using that distribution instead of the very old balbes one, I have started to get crashes about every 5-7 days or so. Did slow down CPU in case it was heat etc, but no luck. Any ideas how I can troubleshoot this ? It just freezes and becomes unresponsive on network (ethernet and Wifi). I have not tried with keyboard/screen. I do have a WiFi power switch connected to it, so one of my other devices can power cycle it, but that is not the right solution. Tried a few upgrades. Downloaded from a source that uses Armbian's name without permission, does not participate in the core development process and confuses users in to thinking that they would receive support for their images at Armbian's place and therefore wasting Armbian's resources. *****/amlogic-s9xxx-armbian: Armbian for Amlogic and Rockchip. Support a311d, s922x, s905x3, s905x2, s912, s905d, s905x, s905w, s905, rk3588, rk3568, rk3328, etc. including install to EMMC and update related functions. (github.com)

But maybe one vendor could be convinced to pay for support, and become the preferred TV-box vendor

If what balbes150 is doing is just dropping support, then everything is fine with me. Forked what I believe are the relevant github projects. My current boxes are running fine, but really wanted an upgrade before moving more onto it. I have 3 S905x3 boxes BTW. If balbes150 is pulling everything offline, and releasing intentionally destructive builds, as I read it, then it is bad. Now, Amlogic is an american company, and I really would expect them to fork over some money to help Armbian. They likely spent money getting Android running. I would like everybody to reach out to Amlogic, and try to have them send money in the direction of Armbian. I guess that is the easiest way to get more support. The cheap chine copycats likely do not want to put money in that direction. Personally, I buy TV boxes because they are way better value for money than the Pi 4. For less money I get a faster CPU, I get eMMC onboard, I get hardware crypto support (Raspberry foundation did not license that), I get a box, and I get a PSU. So the TV boxes are way better value for money. Now, if the Armbian project would recommend brands or models of TV boxes (they seems to be best value for money due to mass market production), I would plan that for future purchases. Maybe some vendor (Beelink whatever ?) would be willing to contribute money for Armbian support. For me, I need 64-bit, 4GB memory, 1 Gbit, ethernet, preferable WiFi, quad-core - good performing CPU not too hot, Hardware crypto, USB 3.0. Don't really care about graphics/sound, as they run headless. And I can do without the I/O of the Pi, using ESP32 for sensor integration. OrangePi, Odroid C4 etc are valid options. But way more expensive. Have some hot running, not too good performing OrangePi devices. Only using one for my 3D printer. I likely do not have the skills and surely not the time to take over support. But as long as we have the current release to start from, then I am happy. Then I can always look at upgrading the kernel if I need. Otherwise, I will just have a stable running box (I hope) for many years to come. Saving the environment lots of CO2 compared to my old AMD x86 based server.

Introducing creeping errors / timebombs in systems is so anti-community/ OSS as it can be. I understand if you drop support, even drop it completely. It works, or it doesn't work. If I had to pay you $10 for a license, I would do that, I have no problem with that. I have created a couple smaller OSS projects as well, and contributed to soma larger ones, but not spent nearly the amount of time you have. I understand the amount of effort that goes into OSS. But you destroying other peoples work because they used software based on Open Source if not a good thing to do, and might actually be illegal in many countries.

My H96max crashed today. Would not boot. is there any way, apart from full reinstall to get it bootable again ? it would only come up with the android recovery. could reboot from SD and create data backup. But still takes time to get the rest of what I need installed. HomeAssistant, so mostly docker containers. But my HA backup is a bit old. But I do have the data dirs but it is not the same.

USB Burn tool worked fine. Read somewhere that I needed the cables, so had them in the bin with all my other recovery interfaces / cables. Now, I have a feeling that I could have used fatload of the image from uboot, and then written to eMMC. Had a little doubt if I should write the image at address 0 or 0x100 ? Nobody tried this ? Should be pretty easy to copy eMMC with dd - to the USB, and then fatload / write it back from uBoot. At least in theory. I know for most people UART access is scary, but now I have my Dupont cables soldered on the pads.

How to do that ? I assume fatload image (made with dd), and then write it to eMMC ? But how to I write it to eMMC ? Can I boot the USB and use Linux to restore eMMC ?

Spoiler inserted.

Here it is. Now I am also getting intrigued and want to learn a bit more about u-boot. I assume the addresses to use comes from the hardware docs ? I have included printenv as well below. Also has some addresses. I can not write the dtb. Partition table error. So I likely need to know what commands to use to boot from the USB, and then when booted, use the install script to repartion eMMC. I can read files into memory with fatload etc. And use that to read a device tree and set ftd address as seen far below And the printenv Store dtb fails:

I can do usb start, fatls etc - So how do I get on from here, assuming the dtb is bad ? (aml-storage etc not found). Possible some fatload and booti (boot Linux image) ? I have loaded dtb, and fdt print works. Bot I do not know which addresses and parameters to use for everything. fatload the uInitrd to 0x20000000 and booti 0x20000000 fails. g12a_u215_v1#booti 0x20000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND [rsvmem] fdt get prop fail. Bad Linux ARM64 Image magic! I am completely new to u-boot, so need a little more help / pointers in the right direction

Booted, made backup, tried to to fresh install. Always booted with SD = / and /boot Made things worse, recovered and installed with the s905 script. Seems now things are wrong. Can't find DTB. Any idea how to recover now ? Still boots u-boot and loads a file from sdcard And seems I can interrupt u-boot process and go interactive. I do have another equivalent box, still new-in-box, so I have a eMMC image backuup there. Also a snapshot = TWRP backup

Thanks, I picked another existing DTB, and that worked for booting. Now I need to install latest snapshot after getting backup. And will put it in /boot

Just checked dpkg log, no kernel upgrade, but linux-image-current-arm-64 is the one at fault. It owns /boot/dtb Now, how do I upgrade everything ? Is there an easy way ? I run almost nothing but HomeAssistant, so I can of course create a HA backup, and read back in on a new system. That is trivial. But I do not necessarily know all the other stuff I set up. I know for sure I do have an outgoing VPN connection to my cloud server that is reverse proxy to my Home Assistant. I do plan to run DHCP/DNS on it, and my USB weather station, and other things for my home automation. Possible even video surveillance - Playing with motion detectors covering camera FoV, so I do not need a constant stream inflow. So we need a way to upgrade. One reason I picked 905x3 is that it performs well for the price according to: https://androidpctv.com/comparative-amlogic-s905x3/ Way better than H6 and RK3328. I am not looking at $100+ devices, then we are close to Intel land, and I would end up in the $250-300 range because I would got for a 8250u or better then. So I am looking at sub $50 boxes for best price/performance/watt.

It is supported by this distro, and thanks for that. eMMC install works, and there is even an install-aml-sxxx script. What is recommended chipset for good performance if I want something else ? The issue is, that /boot/dtb was renamed to /dtb.old and since my dtb was not in, it would not boot. Booting from SD also was not good before I pointed uEnv on card to a standard dtb which I could use to boot. Seems like SD boot switched to eMMC

I am also on H96 Max, with the custom DTB from this thread. apt upgrade today also killed my box. ANd for some reason my SD card also had 2 blank partitions. Did not figure that out before after I had soldered UART wires onto the board. Anybody knows what package destroyed things ? We need to get the maintainer to fix it to stop bricking devices. Currently in the process of burning new SD