jernej

Don't worry, mali driver is built as a module, so unless you load it, it won't eat any resources, except a bit of a SD card storage.

Ok, found the issue. Apply this patch a top of previous: http://sprunge.us/KETE It seems that H3 TV works without calibration, but H5 doesn't. Fortunatelly, it work with fixed value for calibration.

Which is your base branch?

That won't work, because simplefb driver doesn't know how to do that. However, all clocks/gates/resets should be properly disabled during shutdown, if they were correctly specified in kernel and DT (at this point it is hard to tell).

TV base address is slightly moved. Please try with this patch applied: http://sprunge.us/TBPU

Please upload .config for H5 build with composite enabled.

I finished with hammering old code: https://github.com/jernejsk/u-boot/commits/de2_wip Now it should support also A64. Please keep in mind that this is based on latest u-boot master branch. Because of that, I added AXP patch for A64 which might conflict with ATF code (not sure anymore). Above branch was tested on H3 and A64. I thought that H5 support was already mainlined, so I put also H5 defines, but obviously it is not. Feel free to try it on some apritzel branch. I think it should work without any code changes.

H3/H2+ version should work now. One board test should be ok, but please check if I missed any defconfig. I didn't enable composite for OPiZero.

Yes that would be enough. Please just wait half an hour till I rebase the code and add missing CONFIG_COMPOSITE=y in defconfig. But it will be H3 only. I will try to add H5 and A64 code later this evening.

It should be according to BSP code. Ok, I will enable it on all boards where it is easy accessible, so not on OPi0. You will adapt where needed. Does Linux disable all unused clocks, at least on mainline? This is definetly something to be defined in DT. But for now we don't have this in DT, so another option must be used. I will use platform data in DM driver, which should be similar enough to DT, so it should be easier to switch over.

It is based on SID and it changed once in the past, when SID issue was fixed in U-Boot. It was discussed on forum before and search for that post for any technical explanation.

I was thinking about that. Do you think it makes sense? The biggest issue for now is that composite is missing plug in detection code and can't be just left enabled, because it will eat electricity for no good reason for most use cases. I will definetly try to add plug in detection in DM driver. I will do that for sure in the next version of the driver, but I was referring more to the TCON/DE2 details. For example, A64/A83T have HDMI on TCON1 but H3/H5 on TCON0. TCON1 on H3/H5 doesn't have any gates or reset, but on A64 it has. I guess you know what I mean. As soon as I get finished with squashing patches I will start writing DM driver.

@zador, can you check h3_hdmi_tv_v1 branch? I guess you have that in mind. I will think a bit how to add A64 support in (ifdef hell), but I guess that is really not that important, because code in this form won't be mainlined.

It is supported on legacy. OpenRISC core is not used on mainline (yet) but there is some code on the net, which is enough to start playing with it. Of course, suspend/resume is not yet supported on mainline.

It is possible, but for that you have to hack the kernel a bit... If you also use I2C and don't do this clock change right, you can disrupt communication on it.

Well, H series and at least A64 has OpenRISC coprocessor. BSP kernel use it for at least suspend and waking up processor again. For example, it monitors IR sensor and if right command is received, it wakes up the main ARM cores.

Ok, but not today. I will report here when done.

Which version should I take for rebase? Latest mainline?

That explains. Yes, because HDMI VCC is not powered by default. However, you can also pick ATF patch from apritzel or MoeIcenowy ATF repo which does the same thing. Please note that you should not take both patches or ATF won't boot properly.

Yes, it was IRC, just check yesterday(?) log. SRAM is useful for many things and DRAM can also be secured using SMC or something like that. I mean just build standard 64 bit version which is used for Armbian with ATF and mainline kernel - if it boots with video or not.

Oh, that comment has probably a typo and it should be "set sram for video use, default is boot use"

Yesterday or day before there was discussion that ATF in SRAM is not definitive and it could (and probably it will) be moved to DRAM. Please note that also scp (arisc) firmware is located in sram. Currently I don't have time for further testing till late in the evening. Could you test if it clashes with ATF?

Sorry, I was too excited to miss definition of syscon register. Please check above. I found it by searching for known registers which are not described in manual. What exactly that bit does it is mistery for me, but original comment for clearing 24th bit is: "set sram for vedio use, default is boot use", whatever that means.

Found it!!! If I put this in composer init, it works! u32* syscon_reg = (u32*) 0x01c00004; clrbits_le32(syscon_reg, 1 << 24);

Really? Using sun50i_spl32_defconfig I get following output: And dumping CCU reveals that clocks are configured: Maybe it has something to do with 32 bit mode and that ATF is not running? And yes, I also tried that new mode just to be sure, but nothing changed.