jernej

Read this for basic understandment of the problem: https://forum.armbian.com/index.php/topic/3508-higher-uart-baud-rates-h3-nanopi-neo-air/

Here it is: https://github.com/jernejsk/u-boot/commits/a64_hdmi_wip You will currently see only one color on the screen, which changes sometimes, but usually it is green.

That 0xc000003f value doesn't seems to be default. Let's see if it changes something. EDIT: Unfortunatelly, not.

Clocks are not the problem, I dumped values from BSP kernel and they didn't work. BTW, how hard is to dump SMC registers (0x01c1e000) from legacy ATF?

Great, I tried both and only on legacy U-Boot without display I managed to enable DE2. So it must be something with U-Boot or ATF. Do you know if scp is running with legacy U-Boot?

@zador, can you put somewhere legacy U-Boot with disabled display so I can download it? Can you easy create mainline u-boot with boot0? I don't have any infrastructure set up currently for such compilations.

On A83T it is very easy to enable DE2. It doesn't have CCU DE register (offset 0x104). I wonder what is different with A64.

Yes, their campaign failed, but you can still buy this board here: https://mqmaker.com/product/miqi-2gb-ram-fress-shipping/ SoC used in these two boards is also used in Chromebook, which means that almost all HW has mainline drivers in Linux and U-Boot. However, someone is working on VPU driver, but it should be already usable.

Take your time, I will try to make it work on A83T, just to see if it has similar problems. If it has, I think it should be easier to find the issue there.

I mean just for test, because it initializes hw slightly different, so it might have something which is important for DE. If it has, inspection of it's code might reveal the reason.

I don't have access to my HW over the weekend, but you can make following two experiments: 1. With disabled display on legacy U-Boot, deassert reset, enable gates and configure clocks with mw.l u-boot command and check if you can write in DE2 memory. 2. If above works, combine mainline U-Boot with legacy boot0 (SPL replacement) and see if after enabling DE2, writes in this region are possible.

It is worth to check this again. It is quiet possible that this is fixed now. H3 has an HW issue with SID. If you didn't read it in special way at first (longer, more complicated), reading it more directly (short way) returned garbage (mostly zeros). And as you are probably aware, SID holds calibration factor for temperature sensor. This issue was recently fixed in U-Boot, so I think it should be ok now. Do you have any means to check it again?

OE uses 3.0.1 + patches. But I have no intention to update anything. Alternatively, you could share kernel .deb package...

Care to elaborate what is needed to debug ATF? Do I need special build of U-Boot or ATF or both? Did you already check that? Funny is that DE2 is the only component from TCON, DE2, HDMI and TV that can be secured and it is the only which doesn't work. Maybe a coincidence, but I think it is not.

Actually, simplefb is not part of U-Boot framework, at least not in sunxi_display2.c, so I can instantiate whatever combination and add any DT node I want. Only question remains how to signal which combination is wanted. Unfortunatelly, this driver is loaded early, so only pre-existing (stored) env variables would work. Yesterday I find a way how to instantiate "driver model" drivers without a need to be referenced in DT (currently only way towards mainlining the driver). This framework AFAIK supports multiple screens, but not simplefb. However, if UEFI is enabled, similar functionality as simplefb can be achieved trough it. And yes, I took a look at DRM driver. I guess TV out driver should be achivable in near future. I tried to find the difference, but I couldn't. SPC seems to be disabled on legacy U-Boot, unless if I saw only non-secure version - all zeros. I played with it anyway, but I didn't have any luck. Icenowy will probably meet some Allwinner engineer which should hopefully solve the mistery.

simplefb_tv should have tcon1 clocks listed. H3/H5 display pipeline: TCON0 - HDMI / DE2 \ TCON1 - TV DE2 has in reallity two display engines, one is a bit more capable than the other, but both can be used by any output. Yesterday I managed to get cloned output, for example. Same framebuffer (resolution dictated by HDMI) was displayed on both outputs, TV had scaled down image. But of course, also two completely separate displays are possible. Do you think that any of these two combinations is interesting for someone? BTW, neither me or Icenowy managed to fix A64 version. Something weird is going on, so it will have to wait a bit.

Well, you can get higher baudrate with default settings, just not 460800. Default peripheral clock for uart is running at 24 MHz, which is predivided by UART by 16. So your base clock is 1.5 MHz, which translates to highest rate of 1.5 Mbaud per second. I can confirm that this setting works (used for streaming audio through bluetooth on BPi M2+). You can get only baud rates which have integer divider or close to it. 115200 works (divider 13, ~0.2% error), while 460800 doesn't (divider 3, ~8.5% error). I read somewhere that serial communication works if error is <2%. So if you looking for similar baudrate then 375000 or something around it should work. Here you can check table of minimum input clock requirements for some standard baudrates. Unfortunately, I don't know what is the best way to change APB2 clock, which should be >= 30 MHz for 460800 baud. What is even more worrying is that Allwinner programmers rather lowered rate from standard 3 Mbaud/s to 1.5 Mbaud/s for bluetooth than find a proper way to use higher baudrates (changing input clock).

That won't help you, because also another driver is changed, which is built in to the kernel (disp2).

No, openelec is single user system, where everything is run as root, so there is no sudo available or needed. Generally, no matter the board, cec should behave the same. I guess it all depends on which version of libcec you are using. I think that jodamm is not the latest and OE version is one of the previous versions + some patches. You should check if the newest available + sunxi patch works better...

If you load this module, it should be enough.

Of course, A64 doesn't have TV out AFAIK. I meant sunxi_display2.c

Basically I tested it only on OPi2 and there it works nicely. If HDMI screen is connected, then HDMI is used, otherwise TV out is enabled. The only possible drawback I see is that TV out detection is not implemented and it unconditionaly enables it if HDMI is not connected. This is the same behaviour as in video driver for older chips. Small note, I updated the driver and simplefb node in DT for TV out must have a different name "de0-lcd1-tve0". Reason for that is that TV out has different clocks, which get disabled at shutdown - DE2, TCON1 and TVE0. Now, I will try to make it work on A64.

@zador, I just added support for TV out, PAL and NTSC standard. Do you think that it is interesting enough to include in Armbian? Maybe for OPi0? https://github.com/jernejsk/u-boot/tree/h3_hdmi_tv_v1 You have to include "CONFIG_VIDEO_COMPOSITE=y" in defconfig. PAL is selected by default and can be overriden by environment variable.

I don't use PC2 currently. I know limitations because I wrote U-Boot HDMI driver which is indirectly used by simplefb driver. You see, simplefb is generic fbdev driver which don't know anything about HW, it can just reuse existing framebuffer, which is in this case set up by U-Boot. However, I got impression that desktop works (based on previous posts). Does it work for you? If you don't see boot logo during boot, then issue is in U-Boot driver.

@think nice things, driver used here is simplefb, which doesn't offer much - no power management, no double buffering, no resolution changes. It is used because there is no proper DRM driver available yet.