You can only access whatever is memory mapped, so RAM and peripherals. In any case, I would suggest to run "ver" first to see if it works.
Posts by jernej
-
-
Well, if you put in SD card, then there should be no issue rebooting, even if eMMC image is intact. It should boot from SD card in any case.
Just to be sure, you prepared fresh image? Not upgrade?
-
Strange. I guess there is some issue in U-Boot or DT then.
-
This is it: https://linux-sunxi.org/FEL Booting can be done this way: https://linux-sunxi.org/FEL/USBBoot Unfortunately, this requires another device to boot, so it's not "proper" USB boot, like via USB stick. However, you can use FEL to boot and use USB stick for rootfs.
-
To be honest, no idea. I had similar issues with my board too. Sometimes it worked better and sometimes worse. I would say timing issue is most likely (that can be adjusted), but it could also be improper ethernet PHY power up sequence which can cause some issues with proper operations. For that I would need oscilloscope to measure but I would need to borrow one.
You can try if instead of rebooting, complete power off and then power on helps. That includes pulling out power cable. That way you can simulate first power on.
-
"UBOOT RECOVER"
That's FEL mode on USB. This means one of the USB ports can be used for it. It's supported on USB OTG, but from the image you provided, it's hard to say which one is it. Since I don't see any usual OTG port, it's most likely that you would need non-standard and dangerous USB A to USB A cable for it.
Sorry for further disappointing you, but this board only has NAND storage, which is not supported by LE. You could still run it from SD card, but I don't see any socket for it.
-
-
Press "o" during playback and you'll get codec and rendering info. Sure, Android looks ok because it uses vendor drivers. Ones used here are not stable yet.
-
Let me guess. That's HEVC codec, right? I know workaround in code (disabling AFBC), but that would likely prevent 4k@60 to work (actually not sure if it works now).
-
To be honest, I don't know. IIRC there's a long thread about it on Armbian forum due to RAM initialization issues. So I would hazard a guess and say no.
-
So I found the bug with Zero2W image. Here are prebuilt images, without working audio, so you need some kind of USB audio card:
-
I updated above branch with OrangePi Zero2W target, but unfortunately it doesn't run. I need to solder serial console before I can continue debugging. Zero3 works fine though (without the audio). If anyone wants to experiment, build command is:
PROJECT=Allwinner ARCH=aarch64 DEVICE=H618 UBOOT_SYSTEM=orangepi-zero2w make image
-
-
-
-
-
sky42 since I don't follow this topic, is TL;DR version that "max bpc" property is 0 at boot and your script bumps it to 10?
If so, this is from what I can tell kernel bug. First, lower limit is 8, not 0. Secondly, kernel code initializes "max bpc" property to max, but it's later overwritten to 0 in reset state. This will be changed in large HDMI related patch series, more specifically in patch 10. However, it's not marked as a fix (since it's part of rework and I'm not sure if it's really considered as a fix), so it won't land in stable kernels.
-
Eh, this board, while it's pretty similar to Tanix TX6, has some unresolved issues. Since I don't have it, I can't debug issues and it's thus unsupported.