Gunjan Gupta

I know our kernel is too different than mainline, but I don't think they will silently ignore the patches. We might get some review comments on it that might either acknowledge the problem, or point to some other place where problem can exist. The "drivers/rtc: rtc-sun6i: AutoCal Internal OSC Clock" patch series is a nice example where the mail was not simply ignored. Granted its not merged, still I think the knowledge gathered from external review would be valuable. Also main reason for asking was that It might also become beneficial for someone else who might not be using Armbian but still might be having similar problem from time to time. PS: its just an advice. And up to the contributor to take it or leave it. I am not using Armbian on any of my SBCs anyways.

This sounds more like it. I lack the kernel knowledge required to review it myself. I would suggest to try submitting the patch with the explanation in the cover letter to mainline kernel and see if we can get it accepted there.

It can be as simple as /boot/firmware not being mounted. Do you see /boot/firmware in output of mount command?

I honestly don't remember it now. But it can be this one - https://github.com/armbian/build/pull/5619

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