Gunjan Gupta

Debian seems to use the following CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 Fedora has the following CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

$ grep 'CONFIG_LOG.*SHIFT' config/kernel/linux-sunxi64-*.config config/kernel/linux-sunxi64-current.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-current.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 you can also use './compile.sh BOARD=orangepizero3 BRANCH=<branch> kernel-config' to get to the kernel menuconfig and change the same.

Does it boots again if power is plugged out and plugged back in?

Hmm... I only found one mention of that image on the forum and nothing else. Can you share the content of /etc/armbian-release file? That file generally has the commit id in it which can help in tracing the sources. I believe thats because its using hdmi for most of the logging. Thats also the case for our current images, hence I asked you to set console=serial to use serial for logging instead. As this image works, you can either use armbianmonitor -u or dmesg to get kernel logs and share the same. @goingWhat type of power supply do you use? Are you also using a power supply with barrel jack connector? What is the power rating for the your power supply?

@Tu HuThe changes in kernel and userspace can make the device request more power, I guess that can be a reason why you feel that old image works well. Could you please share the link to the old image that works well? @goingDoes the latest nightly image works well for you?

ok... were all the power supplys barrel jack or did you try micro-usb as well. I personally use raspberry pi official power supply for my allwinner devices as it supply 5.1v instead of 5v. That generally makes allwinner devices run more reliably for me. If you have one of them, I will suggest using the same.

That seems correct. gpiochip512 + pin 83 = 595.

Went through cm4 dts. Based on that you should be able to see all pins including GPIOX_18 available in the output of pinmux-pins file present in the ff634400.bus:pinctrl@40-pinctrl-meson directory. Use the pin number from there.

Thanks for sharing the output. I can see 2 things from the log. The kernel didn't paniced, neither did a graceful system restart occured. System was booting fine and all of a sudden it got restarted. This tells me that you most likely have problem with your power supply which seems not able to cope up with the load and is resetting the device. Try using a different power supply

Also could you please try copy pasting the output next time instead of using snipping tool? Not sure why shared output of ls instead of cat like I asked. The ls output is not really usable cause its truncated

Not an amlogic person and I couldn't get much information on it except that its supposed to be pin 83 on second chip - https://elixir.bootlin.com/linux/latest/source/include/dt-bindings/gpio/meson-g12a-gpio.h#L111. So my wild guess is try using 680 as the pin number.

can you share the output of "cat /sys/kernel/debug/pinctrl/*/pinmux-pins"

Hmm... probably using -g was not such good idea after all. Things are all overwritten and almost illegible. But it seems you have switched images around. I noticed in your screenshots the u-boot version was 2024.01-rc5 which mean't you were using the image from the url that I shared. But now in the log.txt, I see armbian version as 23.10 which means you used @going's image this time. The link I shared was the nightly image of Armbian. Changes from that image will be in next release. Could you please get the logs for the same?

@Abhishek Chr It generally is better to tell the context behind the issue as well. For example its possible you are expecting pin 493 to be there because may be its there on raspberry pi. But this is not a raspberry pi and is using completely different chipset. Pin numbers can be completely different. Hence it will be better if you tell what you are trying to achieve rather than what you are troubleshooting at the moment.

Seems to work fine for me. root@orangepizero:~# picocom -b 115200 /dev/ttyS1 picocom v3.1 port is : /dev/ttyS1 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready ggggggggggggggggggggggggggggggggggggggggggggggggggggggg As the headers doesn't come preinstalled to the device, I will suggest you to check if they are soldered correctly. Also make sure you are using pin 8 and pin10 as given in the schematics. Thats 4th and 5th pin when counting from the end closest to the leds on the inner row of 26 pin headers.

@Tu HuGenerally the programs like picocom has options to log output to file. For example with picocom one can use -g <filename> to log output to the specified file. That way you don't have have to spend time taking screenshots. Instead you can just share the file afterwards Could you please plug the sdcard to your linux computer and add following to the end of boot/armbianEnv.txt? console=serial earlycon=on verbosity=7 extraargs=debug panic=0 Now boot again from the sdcard and share the captured serial output

Theoretically modules should get loaded automatically based on the compatible string in the dts. But we can always check if that is not the case and add MODULES to board config to force loading them. Another option can also be to add status=disabled for the dts node in LonganPi's dts to disable the dts node belonging to the kernel module to prevent the module from coming into action.

One possible option can be to convert the configs that are creating problems to be built as modules and then blacklist the modules using MODULES_BLACKLIST in board config.

Sorry, I am not sure what you meant by that. As far as kernel config is concerned, all 32-bit allwinner boards uses config/kernel/linux-sunxi-* and all 64-bit allwinner boards uses config/kernel/linux-sunxi64-*. If required, you can change the kernel config using ./compile.sh BOARD=<board> BRANCH=<branch> kernel-config command. All boards uses their own uboot defconfig files to generate u-boot config.

@Tu HuDoes this image works? https://github.com/armbian/community/releases/download/24.2.0-trunk.449/Armbian_community_24.2.0-trunk.449_Bananapim3_bookworm_current_6.6.13.img.xz

Have you tried using this overlay -

I don't see anyone touched anything regarding this board in git history. Do you happen to have any extra patches for this board in your fork? Whats the uboot version you are using in your fork? Can you share the url for the branch from which you have created Armbian_23.10_Bananapim3_bookworm_edge_6.4.10_minimal.zip?

No I don't know everything. Infact I always say that "Knowledge is like an ocean and we spend our whole life to get a drop out of it" But you seem to lack common sense of not touching things that are not needed to be touched. And it seems you get offended when someone tells you otherwise. Because I am maintainer of only one H618 device i.e. Orange Pi Zero 3 which is quite new community supported device. I have other platinum support and standard support devices that I am maintainer of to support and that take more priority than this device. Let me know if you need help with it.

It would probably be easier to just add the dts and start adjusting the same rather than adding all those vendor patches first. We already know that except audio, dma and iommu everything else is there for H618. Regarding AIC8800 patches, put them in patch/misc directory and add a section for them in lib/functions/compilation/patch/drivers_network.sh

Thanks for reporting . Will take a look over the weekends and get back to you.