Gunjan Gupta

That part I understood already. I was just trying to track if this was a supported device so that I can track if the update that broke your board was from Armbian and what could have went wrong. Wasn't aware of background context as that was certainly not mentioned in the first post. I would leave you guys alone to discuss it further.

@Serjaru You have still avoided my question and haven't answered what Image you are using? How can we try to help you without knowing what you are using. Only thing I know is you probably are using Orange Pi Zero as you have posted with that label. Last full week I was un-pluging power off my own Orange Pi Zero as I was trying to check working of my own project. I would have done it 50 times atleast and not a single time I had corrupt sd card. So please stop avoiding questions and provide details. Otherwise no one can help you.

@HorstAlso share output of `dmesg | grep dwmac`

@HorstCan you share the output of `neofetch` command just to confirm you are using Orange Pi 3 LTS and not Orange Pi 3? Ethernet is working fine for me on both 6.1.63 and 6.6.2 kernels

@HorstIIRC fsck it already part of initrd and will run on boot. You have mentioned that you are using Bullseye. Its been almost a year since we generated any bullseye based image. I would recommend you to either use the latest bookworm based image or generate a new bullseye image yourself using the build framework. Instructions for generating new images can be found here - https://docs.armbian.com/Developer-Guide_Build-Preparation/

I don't see Compulab Utilite Pro listed on Armbian's download page. Could you please confirm which image you are using and the URL for the same?

Just for the sake of curiosity, Could you please share the output that you got on uart with the problematice value of CONFIG_DRAM_CLK set?

We have ended support for MangoPi MQ Pro and Nezha as the images were not building and there are no maintainers for these boards. Other images for boards that are still supported will come back in few days as posted by Igor in the Announcements section.

Probably, it will also be a good idea to add fdtfile=sun4i-a10-gemei-g9.dtb Just to make sure that your device specific device tree is used.

if you can mount the sdcard and see the contents, then try editing boot/armbianEnv.txt file and the following at the end of. the file earlycon=on extraargs=debug verbosity=7 console=serial This will get you more output on your serial port and then we can proceed based on the same

Alright then, one less place to look. Honestly, if its not already posted by someone on the internet and its not marked on the board, then you have to find it out yourself either using trial and error or by using a logic analyser.

This is a shot in the dark, but try the golden round pad beside the heatsink above the konsemi chip. That can be the clk. For ground, you can use the one available on the side for uart. Or you can also use metal shields on top of usb ports. That box of yours is already soft-bricked. What more can go wrong?!!! lol

Interesting...I tested the 32-bit Allwinner kernel before we release on a H3 board and it was booting. You can give images from the archive a try. You can also try creating image yourself, Use branch as edge and it will create an image with 6.6 kernel. Instructions for building an image can be found here - https://docs.armbian.com/Developer-Guide_Build-Preparation/

Currently Armbian is not building debug kernels.

@teknoidI wonder why you suddenly commented on 5 months old thread that had no activity what so ever

Can't say. As I said I don't own any rockchip device and hence never looked into rockchip specific details. The answer to that can vary based on SoC's bootrom implementation

What I have seen with most android devices, including android tv boxes is that there is a key burned on the CPU which is used to identify the bootloader that is run on the device. This is generally done by the device manufacturer to make sure that device is not tempered with and to make sure 3rd party software is not installed on the same. I believe by installing bootloader, you have bricked the device as armbian bootloader is not signed by any OEM key. I am not rockchip person, and don't own any rockchip devices, so I can't say whether this can be recovered or not. Probably others can comment here.

@ctag Unless you have tried to override the BOOTPATCHDIR environment variable, your second patch path i.e. userpatches/u-boot/u-boot-sunxi/board_orangepizero2/orangepizero2_light_red_led_on.patch is correct. If you had passed BOOTPATCHDIR=v2023.10 on the commandline, first path would have worked as well, but it would have ignored all the patches that are currently applied by Armbian as we are using BOOTPATCHDIR as u-boot-sunxi. I tried both of your patches in my checkout, and both of them failed to apply. See the output here - https://paste.armbian.com/uwapayuqiw.bash. In the shared output you would see its considering the file that I added based on your second patch and failing to apply the same.

Easier method: create an device tree overlay and use the same. /dts-v1/; /plugin/; &{/soc} { ehci0: usb@1c14000 { compatible = "allwinner,sun8i-r40-ehci", "generic-ehci"; reg = <0x01c14000 0x100>; interrupts = <0x00 0x27 0x04>; clocks = <&ccu 0x2f>; resets = <&ccu 0x17>; phys = <&usbphy 0>; phy-names = "usb"; status = "okay"; }; ohci0: usb@1c14400 { compatible = "allwinner,sun8i-r40-ohci", "generic-ohci"; reg = <0x01c14400 0x100>; interrupts = <0x00 0x28 0x04>; clocks = <&ccu 0x32>, <&ccu 0x7f>; phys = <&usbphy 0>; phy-names = "usb"; status = "okay"; }; }; Assuming I didn't left any syntax errors in the above overlay, you should be able to create a dts file with the above content and then use "sudo armbian-add-overlay <dts-filename>" to enable the same

@mrfusionIf you have flashed Armbian 23.8 or later than you most likely will already be having crust support built in. On Pine64 however the crust configuration in use is a generic one and is not taking AXP chip in account. So power consumption might stay on bit higher side. But otherwise everything should work fine. If you are unsure about crust is already enabled on your board, use sudo armbian-config > system > install option to flash latest u-boot

Nice to hear edge worked for you. Apart from the fifteenhex repository used by Inovato, I have also found another Xradio XR819 driver which looks kind of cleaner but also need some work as its tightly coupled to some sunxi bsp drivers. I am going to try bringing that up as well. But it will take some time as there are other boards to support and there is not a lot of interest around xradio anymore.

Sounds like bad hdmi cable. Try using a different cable

there is motorcomm yt85xx driver (CONFIG_MOTORCOMM_PHY). It works for Orange Pi 3 LTS's yt8531c ethernet. Can't say for your device. Just try it out.

Its weird that xradio is working for orangepi zero but is not working for Quadra. Waiting for @Tenkawa, to test and comeback on the same.

Yeah, I will suggest to update the system if possible. Opensuse 15.1, 4.12 kernel and docker 19.03 all are quite old. You will have better experience if you can update to latest version of opensuse and docker. You might either need support for rootless containers or run the container with --privileged to make sure all the necessary privileges are there