Gunjan Gupta

Could you please specify which armbian image version you experienced the issue with and what was the older version that worked for you?

@kriptonusFYI, the boot issue is resolved and the fix has been merged into latest armbian/main. So you should be able to either build it yourself or take latest nightly images dated 24 Aug or higher. We however have kind of hijacked the thread to resolve other issues experienced by ALIGMSTEN during testing of the fix on this board. You can also give the build a try and let us know of any other issues you might face and we will try to resolve the same.

Thanks, this will be helpful. I will try to find the cause tomorrow

Do you have any files or directories listed in /sys/kernel/debug/pinctrl/ directory or does that not exist as well?

It shows on my H5 as well. Wondering why its missing on H6. May be try sudo /bin/bash -c 'cat /sys/kernel/debug/pinctrl/*/pinmux-pins' Not that I believe the above command will behave differently from previous one. But the output is really important to figure out what is using those pins and causing that error message

On the contrary, I thought that was present, atleast it is present on 32-bit boards. Let me check what is present on 64-bit builds.

Could you please also share the output of the following command cat /sys/kernel/debug/pinctrl/*/pinmux-pins

could you please upload the logs with armbianmonitor -u

Thats great news. We have similar issue with nanopineo2 black as well. And I suspect its the same cause. Sending a image to Igor to confirm. Will raise a PR with the fix once he confirms

Thanks for reporting the issue. I will take a look for Orange PI Prime and revert back to you

Does bc46fd509a50db4bcef014d79569b68287ecc19b boots or bc46fd509a50db4bcef014d79569b68287ecc19b~1 boots? Notice ~1 at the end of commit id, which means we are checking out the commit before the specified commit id which is exactly 6dd7067c79bb04aa2b17eddcfc3730639c070267 as you reported in an earlier comment as the output of git rev-parse HEAD

We already tried disabling crust and user confirmed that board doesn't boot after disabling crust as well. So I don't think its crust. Could you please try placing the attached patch in patch/u-boot/u-boot-sunxi/board_orangepi3-lts and build with latest armbian build code. Lets see if this boots. 0002-update-defconfig.patch

@ALIGMSTENThanks for the update. So it broke way back when I updated u-boot to 2022.10. Checking what change made it to break

@schunckt I have disabled patch/kernel/archive/sunxi-6.1/patches.megous/media-sun6i-csi-Pass-on-g_parm-s_parm-to-the-subdev.patch as that was the code causing the kernel oops. You should be able to use the camera now with 6.1 kernel as well

The version of softwares needed for booting like bootloader, kernel, etc that are used during the build are defined in config/sources/families/include/sunxi64_common.inc file. When we upgrade these things, we sometimes also have to modify the patches that we apply on top of the upstream software. Due to that reason, simply changing the version in the above file will not work and most probably can cause failures during build process. Following are the commits where I updated either U-boot or ATF For each of the above commits, starting from the top of the above list, you can try the following Inside the directory where you cloned the armbian/build repository, checkout the code that was there before the software was updated using the following command git checkout <commit_id>~1 Replace <commit_id> with the hexadecimal value. For example, in order to check if the board booted before the change done in edc0a5bdfc57485a5eeaf89e54ea6be86881aada, run the following command to get the code back to the state it was before that commit git checkout edc0a5bdfc57485a5eeaf89e54ea6be86881aada~1 Then create the build using ./compile.sh, flash it on the sdcard and see if it boots If the build boots, you don't need to go further down the list. Just share the output of the following command with me git rev-parse HEAD Using that output I will check what change caused the board to stop booting and will fix the booting issue.

try changing &pio to &r_pio when using PL8

Hard to tell from the information I have, which is it broke after jumping to v2023.07-rc6 from v2023.07-rc4. If you check the diff, only dts changed belong to imx family. I don't have the board. Only thing I can do is ask users to roll back to specific commits and let me know if it starts working for them

Sorry not sure what your point is. If its that new u-boot works, I already know that is true for most of the devices. Orange pi 3 being not one of them for some reason

SCP parameter is not supplied because scp.bin is copied to the location expected by uboot by default. Hence there is no need to set SCP variable. Its similar to how we copy atf and never set destination flag for the same. Instead of that, we are using BINMAN_ALLOW_MISSING=1 when crust is not enabled for a board. This results in u-boot generating a dummy scp.bin file itself containing nothing but noop operation. Boards do boot with the autogenerated scp file. I had tested both scenario in details on nanopiduo2 (sun8i H3) board when I added crust support. And later when I got orange pi prime (sun50i H5) I have tested both scenario on that board as well.There is no fault of build system here. And as per Igor, Board was working until 2023.07-rc4 and broke afterwards. We just never got to testing whether the board boots if we rollback u-boot because of Igor's vacations

@goingIgor also noticed that his orange pi 3 stopped booting sometime about a month ago after I bumped u-boot and kernel couple of time. As there is no output on serial, the culprit is most likely u-boot and not kernel. We decided that we will test first by removing crust, that was the change in my branch, and then rolling back u-boot versions.

Thanks for testing it out. That rules out that the problem is caused by crust. Could you please check building against this commit https://github.com/armbian/build/tree/748eba003136a0681a72cab403171cf8e565c529. See if board boots with uboot version 2023.07-rc4? We have bumped you boot quite a lot for allwinner in last few weeks and somewhere between those bumps the booting stopped working.

I got my camera delivered yesterday. Will test and fix its working on 6.1 kernel. @schunckt Could you please try building the image with BRANCH=legacy and see if the included 5.15 kernel works with 2592x1944 resolution? Asking this as 6.1+ kernels introduced maple-tree for memory management and I have seen some cases where memory allocation is failing for 32-bit Allwinner boards.

Interesting. I think it might have something to do with the driver for ov5640. Will get one for testing, but it will take about a week to get delivered. Will update once the driver arrives.

Also could you please try with latest nightly/rolling image from the download page just to see if this is already resolved in newer kernels?

I see you modified something in kernel config. Could you please let me know what were those modifications?