Gunjan Gupta

ok.. I am not sure I follow. Probably its again caused by the translator messing up the description, but still could you please try explaining with less metaphors and more simple language.

@robertojI assumed you were looking for that pin name, number mapping for development. If so I hope that file will be helpful. If you still want the output to be in gpioinfo command, I guess you have to add the overlay as suggested by others. I personally don't use gpiod that much as I find it somewhat lacking. I last checked it in late 2022 or early 2023 I believe and it was only supporting simple gpio operations and was not supporting i2c, spi, etc. I am not sure it changed. But if its still the case and if you require to use more functionality, I will suggest going the MRAA route like I suggested before.

You probably are misunderstanding my comment and intent here. I assumed that robertoj needed the pin number pin name mapping for development and gave an alternative way of finding the same using debugfs. Also my previous comment was simply an attempt of explaining how pin names gets populated in pinctrl directory in debugfs and if its not present in pinctrl directory in debugfs then it probably will be a bug in the pinctrl driver. Looks like both the my intent and what was conveyed is being misunderstood. I was only trying to help.

@ag123Yes, its possible to name in dts. But pins should have their names already defined and visible in the debugfs as they are being defined using a macro https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c#L19 https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sunxi.h#L32 https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinctrl.h#L63

If that also shows the same output. The pin numbers starts from 0 for PA0 to 31 for PA31, 32 for PB0 to 63 for PB31 and so on until PI* lines. So basically there are 32 pins in each lines stacked together and lines are PA to PI making them 288 pins total on gpiochip 0. Then you have PL line on gpiochip1. You should see the names. If its not visible, then it is a bug in kernel pinctrl driver.

what is the output of sudo /bin/bash -c "cat /sys/kernel/debug/pinctrl/*/pinmux-pins" Does that suffice?

Show what? Could you elaborate on your question?

Banana Pi M4 berry and M4 zero are H618 devices that comes with emmc. So I guess it might be possible this patch might solve issue for you as well - https://github.com/BPI-SINOVOIP/pi-u-boot/commit/cbdca15b14fa677df322d9754f30a8da662c10c4 This is just a speculation however. I don't have any of the three devices to reproduce the issue or to confirm if it resolves the same.

yeah noticed that in Nick's repository. The commit says its 5 days old. so not sure if thats included or not. But anyways. it possibly can be that issue that you have shared. Anyway until someone fixes that, I guess you can continue using the sdcard.

Ok...Too long of a video, mostly skipped through the same and didn't watched till the end. I think you need to add CONFIG_MMC_SUNXI_SLOT_EXTRA=2 in your devices uboot config. You can either do that by adding a patch for your uboot defconfig file or by using post_config_uboot_target hook in your board config file. For the latter see - config/boards/cubieboard2.csc for example

I believe yours is more of a generic Linux related question than something that is specific to Armbian. Have you gone through Arch Linux's Solid State Drive page - https://wiki.archlinux.org/title/Solid_state_drive

There is no official Armbian builds with 4.4 kernel for rockpi-e. But rockpi-s has legacy kernel configured as 4.4. I believe you can compare their configurations and prepare the build yourself. Here are some files that you might want to look at config/boards/rockpi-s.conf config/boards/rockpi-e.conf config/sources/families/rockpis.conf And if you are not familiar with creating the builds yourself than see - https://docs.armbian.com/Developer-Guide_Build-Preparation/

Can't say for sure, but I guess you used armbian-install to install root to emmc. Then while still running from sdcard, you tried to check the UUID, which will give the uuid present in sdcard's /boot/armbianEnv.txt file and hence you got the UUID of sdcard. So my guess is when you updated the UUID, you actually ended up changing that on your sdcard too. When sdcard will be removed, the emmc never would have bootloader installed and hence will fail to boot. But with sdcard inserted you will be able to use emmc as root device. Again this is all speculation. Best option to tell will be if you can share screenshot of armbian-install's first screen highlighting which option you choose to install to emmc.

Sorry but I am confused about this part. Why did you had to modify the UUID yourself? Armbian install has the option to install bootloader to emmc. Not sure if you used it, but if not try using the same. It generally helps to see the serial console logs when troubleshooting boot issues, so if you can share them that will make it easier for people to help you out.

@EragosWas there some issue with running apt-get install linux-headers-current-sunxi?