jernej

I have zero idea what is that about... As I said, it looks like some image building issue, but don't hold me on that. BTW, can you try to boot ordinary OPi3 image and see if there is same issue? it should mostly work.

Note that actual address is in reg property, it's just convention that address is in node name too. So make sure you fixed address in both places.

No, output method is always the same as input. Anyway, RX on Arduino still operates at 5 V internally, so it might not reliably decode 3.3 V signal (it can be even slightly lower than that). Why don't you just fix regulator address first and see if this is it? As I mentioned, boot reliability issues can come from incorrectly set voltage regulator.

No, U-Boot (currently) doesn't set any voltage regulators for H6 boards. However, ATF does, but it works with both busses (at least new versions). But even this is not really necessary. Most important regulators already run at power on. You can boot to Linux with them.

It's a long time ago since I worked with Arduino, but they usually run at 5 V. This is too much for H6 serial port, which expects 3.3 V signals. I may be wrong about Arduino, though. I highly recommend measuring idle state voltage level on TX pin. If it is above 3.3 V, then don't use it.

Both works, but RSB is faster. I suggest to use RSB, just to be in line with OPi 3 DT.

Yes, you can, but be careful to work at 3.3 V, otherwise you'll damage H6 chip.

@Ukhellfire if that is the DT file you're using, then yes, regulator address is wrong. You see, it can work via I2C bus, where it has address 0x36 or via RSB bus, where it has address 0x745. In DT file you mentioned, it's connected to RSB bus, so address is wrong. Change @36 to @745 and reg = <0x36>; to reg = <0x745>; and all regulator related issues should go away.

How do you access initramfs console? Via connected HDMI monitor? If so, then take a photo of each dmesg page Anyway, serial is basic requirement for debugging boot issues. Anyway, if it's possible to boot sometimes, but not otherwise, it's possible that there is timing issue, insufficient voltage of some regulator or too high frequency. Unfortunately, all of these things are hard to debug, especially remote.

@Ukhellfireboot looks good, except when loading modules. I haven't seen anything like that. Did you by any chance build kernel and modules separately, possibly with different compiler/settings? This is more or less the only reason for such issues.

If you have an option to build custom kernel, you can mark usb keyboard driver as =y and it will be included in kernel directly, so it should work from initramfs shell too.

Initiramfs shell should support dmesg command. If not, remove "quiet" from kernel arguments and you'll get basically the same output on serial.

There is no reason why standard method wouldn't work on OPi 3 LTS. It's possible that something in DT file isn't set correctly, although quick comparison doesn't show anything useful. Show me output of dmesg, maybe there is something useful there.

If you have image with mainline U-Boot, you can first burn it to SD card, boot it and then butn same image to emmc directly. Only precondition is that emmc is enable in both, U-Boot and Linux.

I don't remember which version was first. I guess 5.15? There is also one patch, which was merged already, so you need to dig it up from rtw88 history. As I said, I don't have them. I deleted them at one point. Anyway, it's simple, adding new variant to BT RTL driver and making sure module is reset before use (patch for this is on BT mailing list).

I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.

If there is no status line, it's considered active. You have to set status to "okey" only when parent node sets it to "disabled". For example, sun50i-h6.dtsi has spdif node set to disabled. In sun50i-h6-tanix-tx6.dts we override status to "okay".

SPDIF is already included in base H6 DTSI file (any board can easily enable it, if present) and it will be enabled for Tanix TX6 by default in 5.17

No, not really, only general instability (app crashes, kernel lockups, etc.). Note that Android has completely different display stack, so you can't compare it to X11. If you really want to prove it's driver issue, you would need to create BSP based image and test it there. But I never done that for 64-bit Allwinner SoCs, so I have no idea how hard it would be. Strange, your DT blob has this: awleds { device_type = "awleds"; compatible = "allwinner,fd6513_dev"; status = "okay"; leds_clk = <0x87 0x07 0x05 0x01 0xffffffff 0xffffffff 0x00>; leds_dat = <0x87 0x07 0x06 0x01 0xffffffff 0xffffffff 0x00>; phandle = <0x1bd>; }; which clearly indicates it should have FD6513 LED driver and thus display. Maybe it's one image for several box variants.

Few differences I see: - different drive strength for wifi (lower than TX6) - not that important - slightly different eMMC settings (lower frequency, etc) - might be important - different IR key codes (nothing surprising) - it seems that slightly different LED display driver is used (can't be sure unless I see detailed PCB photo) - T95 max has slightly higher DRAM frequency (672 MHz) vs. TX6 (666 MHz) - different DRAM config, but it's unclear how much they influence stability

It's possible T95 MAX uses slightly different DRAM configuration. Ideally, you should extract DTB file from Android (/sys/firmware/fdt is actually DTB file used by kernel) and then we can compare settings.

I know about the changes, I'm the one who made them. However, everything works for me . Note that there are some issues with 5.17-rc releases due to some sunxi pinctrl driver bugs, which were resolved recently. Last patch is not applied yet.

You don't need to wait so long, just pick mentioned DT lines.

No, because I don't care about Apple products.

No, but I'm in contact with few of them. In fact, my job has nothing to do with Linux, although this will probably change in near future. It's just a hobby for getting some experience with developing various Linux drivers and learn how things work nowadays. You won't see me writting userspace apps, except for testing purposes or improving existing code which use drivers I'm working on. I follow few tutorials for character devices on net. But I find it easier to study existing drivers, especially if working on something new. Linux has well documented common code and there is a ton of helper functions. Reading various slides from presentations of particular subsystem also helps. You have to find the method which works for you. There is no single source for that either. Also depends what you mean by reverse engineering. Nowadays there is BSP linux source which means you just have to understand that code, but many times even this is not an easy task. But if you mean hard core reverse engineering, like analyzing binaries and trying to understand what they do, that's another beast entirely. It helps if you learn assembly language for target system, read a lot of tutorials, guides, etc. If you can solve various crackmes, then you're already better in this than most people. But truthfully, you really don't need that to be good kernel developer. However, I already found few interesting things that way, because Allwinner hid some things in binaries which were later linked in driver directly.