Gunjan Gupta

Thanks for reporting, I will take a look and get back to you on the same.

The latest available kernel is 5.15.137. It should be available in the beta repository. Can you give that a try? Make sure to update kernel, u-boot and the bsp package to avoid having any boot issues. Alternatively you can flash a different sdcard with the nightly image for testing.

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

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?

you can also try dr_mode = "otg"; that way when you will plugin in an otg adapter, it will switch automatically. There would be no need to mess with gpios yourself.

Nice work. though this might all get overwritten on next upgrade. Hence I will suggest you to convert those dtb changes into a device tree overlay. These might help you with the same - https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ - https://docs.armbian.com/User-Guide_Allwinner_overlays/#using-custom-overlays

Depends on boards and vendors. Raspberry pi and allwinner works, Khadas vim1s and vim4 doesn't. Not sure about rockchip boards, I don't have any so haven't tried. Some vendors uses closed source toolchains with binaries available only on x86 platform for building bootloaders or kernels. Just give building a try, if there is a restriction like that, it will let you know.

This being cheap actually makes sense. Most of the photos shows its usb to usb. So no ac to dc conversion required, no need try implementing something like quck charge support or something. That will leave it with just requiring a male usb port, a female usb port, a led, a button, a relay (or who knows may be its simply using a transistor inside) and most likely a esp8285 module. All of those costs only few cents. I personally won't mind buying it as long as I can easily open it to replace it firmware. Would most likely replace it with zephyr or micropython or nodemcu and put it back together. That way I would know for sure I am not installing a backdoor into my network.