martinayotte

I kept the default ENV which was in your original image : initrd_start=0x39000000 I will try to change that according to your boot-aml-s912_ENV.cmd later ...

Here it is :

All my Allwinner boards are currently on 5.6.0-rcX, but since it still RCs, I didn't committed my change to Armbian repo yet ...

Thanks ! At first, I've wished to keep /boot files and stuctures in the rootfs partition like normal Armbian, it works fine when booting from SDCard using those u-boot commands : But for eMMC it doesn't work, even doing "ext4ls mmc 0:2 /boot" shows an empty directory while doing "ext4ls mmc 1:0 /boot" for SDCard is working fine. It seems that eMMC driver within this old u-boot requires that files need to be at root level, probably not able to browse sub-folders, so the above commands works if all paths are root / ... If I'm using the FAT partition, the following commands are the ones needed :

I can be that "Guinea pig" ...

What do you mean ? Documentation about A20 in general ? https://linux-sunxi.org/A20

Do you mean a custom version of 8250dw with RS485 emulation ? In this case, I've used some patches similar to those one : https://lkml.org/lkml/2018/6/1/344 Doing such custom kernel build applied to all UARTs, enabling RS485 mode is done by an userspace ioctl call.

I don't understand your question, all A20 UARTs are always using the 8250dw driver, as well as any other Allwinner SoC. EDIT: If you mean that you simply wish to enable later from userspace, yes, that is possible by loading overlays dynamically ...

No ! They are not recognised, but defined, due to the following kernel configs : CONFIG_SERIAL_8250_NR_UARTS=8 CONFIG_SERIAL_8250_RUNTIME_UARTS=8 The only ones that are recognised are the one you see in "dmesg", therefore the UART6/UART7 are accessible from /dev/ttyS1 and /dev/ttyS2 respectively ... If you enable some other UARTs using overlays, this order will of course be changed.

There is no "special" boot configuration since U-Boot rely on the 3 symbolic links which point to proper Image/uInitrd/dts . It is possible, but then you have to manually install every things and create the symbolic links as well as creating uInitrd using "mkimage". It is much more easier to use Armbian DEBs ...

If you used Armbian build scripts, it will produce a linux-image-*.deb, and when installed using "dpkg -i", it will take care of changing symbolic links in /boot and create new uInitrd file.

It must be something else since my board is booting fine even after adding this firmware blob ...

Those errors are that kenrel try to load DirectPort blob, which Armbian doesn't provide, but this doesn't mean that it prevent HDMI to work. If you simply wish to get rid of those error you can grab this blob and copy it into firmware folder and reboot : mkdir /lib/firmware/rockchip wget -O /lib/firmware/rockchip/dptx.bin https://github.com/wkennington/linux-firmware/raw/master/rockchip/dptx.bin

It should have worked ... Did you look at boot time if overlays produced errors ? Did you look at "dmesg | grep tty" ?

Right ! (I was answering too quickly ...) No, the 0x means hexadecimal, you can still use it but PG12 would be "interrupts = <0x6 0x0c 0x0>;", not 0x1b which means PG27 which doesn't even exist ... I'm not fluent with interrupts, but I would try "interrupts = <0x6 0x1b 0x2>;" where 0x2 means IRQ_TYPE_EDGE_FALLING

No ! In your case, you should declare function parameter as either "gpio_in" or "gpio_out" as described here in drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c Note that this driver doesn't mention alternate function for PG12, so simply use "gpio_in" ...

In this case, defines are there : include/dt-bindings/interrupt-controller/irq.h Ah ! Ok ! I didn't look at A13-SOM schematic, but A13-OlinuXino-Micro one ... I don't know, IRQ_TYPE_EDGE_RISING=1, since your previous test with 0 was meaning IRQ_TYPE_NONE.

Ok ! So, it is like that since prehistoric time ...

Actually, this behaviour was already present in all general-packagin-X.X.y.patch, so I don't know why, maybe because it didn't work. Maybe @Igor knows ... Most probably ... What are the artefacts left ? symbolic link ? Feel free to provide your modifs and we will look at them ...

Banks are defined as A=0, B=1, ... and G=6, etc ... Right ! ACTIVE_LOW=1 and ACTIVE_HIGH=0, other flags can be seen in include/dt-bindings/gpio/gpio.h BTW, are you sure that you need to use PG12 for Interrupt ? Because on the schematic, PG12 is used as output for USB0-DRV ...

But maybe with some images for other RK3399 boards it will boot, you have to try them out ...

I didn't knew that ... In such case, OPi4 images should have HDMI working fine too.

What do you mean by 4B ? I've never heard that a new version came out ... Mine is OPi4 rev1.3 ... EDIT: maybe you mean RockPi4B ? EDIT2: With my RockPi4B, I've some flickerings but visible text on my Dell monitor, and with my HDMI 8in. LDC I've some worst flickerings without text displayed ! So, RockPi4B has HDMI troubles ...

Although I'm running my OPi4 as headless, so no desktop, I've tried two different HDMI monitors and both were working fine with my 5.5.0 image.

Most probably with the output of "dmesg" ...