Most of the time, AW boxes come without root password, but there is this very old trick: https://olimex.wordpress.com/2016/05/10/how…d-linux-kernel/
In any case, I suggest #linux-sunxi IRC channel on oftc server for further help. This is not general dev forum.
Provide a debug log, there is just too many questions.
one question, 12.0 release uploaded on wesnesday has ethernet issue fixed or will you launch new one?.
No, official LE12 release doesn't have this fix, but it will be in next point release. However, image that I uploaded is basically LE12 source + fix, so you can use it till point release.
Great! I'm glad it works. I'll prepare PR next week. I guess you can use this image for foreseeable future.
Making proper board support means creating device tree file and proper U-Boot configuration. This gives you board specific binaries which can be also used for FEL booting. In the H3/H2+ era, this was done by first dumping firmware from the board and extracting script.bin, which is then converted to human readable named script.fex. This file contains all board specific configuration, which is used for creating device tree file and U-Boot config. In any case, you have to first obtain access to existing system, so you can dump it. Since UART doesn't work, I don't have idea how to do that.
jordixPI3 I updated test image here: http://jernej.libreelec.tv/test/opi3-lts/ Please test.
I tweaked RX delay on PHY and ethernet controller to be in sync with schematic and vendor kernel. It adds 450 ps delay in total, which may not seem much, but that's a lot when talking about gigabit ethernet. Additionally, I slightly tweaked reset timings, which will ensure PHY is properly powered up.
In any case, my quick test showed that it works.
FYI, I finally found datasheet for ethernet PHY, so I can experiment with more sensible settings. Maybe I can figure out more stable values.
Nope, FEL doesn't produce serial output on its own. But you can run binary which it can produce some.
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.
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.
I unfortunately don't have OrangePi PC to test this. I checked OrangePi Plus2E, but everything works fine. Can you connect serial console and see what, if anything, is outputed during boot with non-working U-Boot?
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.
