I have 3 questions, this is for a TV box, H96 max+ , hardware is a bit unusual, the regulator (no uSD after uboot)
Closest is Rock64
In the armbian forum, under TVboxes , hexdump made a dtb, rk3228-t9.dtb that also works on H96max+
No one seems to compile the SSV6051 module, wifi
Ok, I hooked up serial, putty, uboot wants a fdt , rk3228-rock64 in /boot/dtb/rockchip/
But, but the download is bad, the img extracted OK, so not a bad download
but the uSD wouldn’t mount until I did a fsck, and mount -o loop,offset=$((512*32768)) …
says wrong fs type, bad option, bad superblock…
So, something that needs fixing
–later–
I see that it is a supposed to be a gpt disk, but missing some partitions, but it still should have mounted
Out of concern for my sanity, I tried again
The contents are clearly damaged, and missing parts?
An unusual start for a mbr disk, which it claims to be
It gives the same error msgs as previous post
wdt
You mean you installed the Rock64 image on the TV box? Not sure if this is going to work at all.
/boot/dtb is a symlink to /boot/dtb-<version_string>-rockchip64 which contains the dtbs.
There is only one partition, I guess MBR, at least it is no EFI image, so no additional partitions required.
How did you try to flash? What you mean by extracts fine? If you do this by non-proper flashing tool or non-proper file system, then e.g. symlinks, ACLs, permissions might be lost. This image should be flashed by dd method, e.g. via Rufus or Ether.
I have the “right” dtb for the hardware (t9, really H96max+), armbian boots OK, few or none error mesgs in dmesg
If the dl was bad, the xz would be corrupted, fail to extract. I used etcher, refused to mount (after), needed a fsck
After that, there did not seem to be any dtbs. I looked in both directories
Running fdisk on the image, then mount -o loop,offset=$((32768*512)) … , also fails
–edit-- I do have a serial connection, essential for board hacking
wdt
Confirmed, that image was not packed very well, partition size left larger then final image file size. However contained data was not affected.
I repacked the image and was even able to further reduce files system and partition size. Could you try this one: https://dietpi.com/downloads/images/testing/DietPi_Rock64-ARMv8-Stretch.7z
What I could not replicate is the missing dtb files. In both images those are apparent in my case:
root@VM-Buster:/mnt/rock64# ls -lh boot/dtb-4.4.172-rockchip64/rockchip/
total 7.0M
-rw-r--r-- 1 root root 84K Jan 29 2019 px30-evb-ddr3-lvds-v10.dtb
-rw-r--r-- 1 root root 88K Jan 29 2019 px30-evb-ddr3-v10.dtb
-rw-r--r-- 1 root root 87K Jan 29 2019 px30-evb-ddr3-v10-linux.dtb
...
Rufus and Ether as well have no issues with the wrong file size, which makes sense since the target drive is large enough. This should only have an effect when attaching the image file as loop device. On first boot, partition + fs are resized to fit drive size, which should be the latest step where error is gone. Regardless an image file should never be truncated to a smaller size then partition end. We wrote a new image+archive creation script which assures that.
Good day
yes, that is OK, still won’t loop open with offset 32768, but etcher writes it OK, and there are dtbs
It booted OK (with my dtb), I had to scramble to find password, but the wifi (mt7601u) failed to connect
It IS a bit distant, I couldn’t seem to go to alt-F2 to do lsmod to check if module really loaded
I rechecked the wifi-txt, looked OK, if I understand, for wpa-psk only the first 2 entries are filled?
With other distros wifi will stay up for a day or 2, always connected ssh and x11vnc
(armbian184, armbianTV180)
wdt
Jep, for WPA-PSK WiFi, only SSID and key is required. Also enable WiFi in dietpi.txt to have module blacklists removed on first boot. Otherwise you can do afterwards via dietpi-config, including SSID scan and credential input.
You can exit any network check loop (when WiFi did not connect on first boot) via ctrl+c usually on console, then setup WiFi via dietpi-config, then logout+in to finish firstrun update+installs.