<LucasTanure>
Could you guys explain in little more detail what you are talking about on HDMI stuff?
<HackerKkillinghi>
hdmi rx mean hdmi in
<HackerKkillinghi>
hdmi tx mean hdmi out
<LucasTanure>
ok, but whats the problem there?
<LucasTanure>
the HDMI controller has no doc and no driver?
<LucasTanure>
does it work with khadas 5.4 downstream kernel?
<HackerKkillinghi>
hdmi tx has drivers in mainline
<HackerKkillinghi>
but hdmi rx dont
<LucasTanure>
in both mainline and downstream?
<HackerKkillinghi>
khadas has a android build fro vim4, that build has a work hdmi rx driver
<LucasTanure>
ok, so we can port to mainline no ?
<HackerKkillinghi>
amlogic downstearm has amlogic framework that isnt in the mainline . In order to get hdmi rx work in mainline, we need to a driver that use mainline framework insteed of amlogic framework Therefore the only way to port the downstearm amlogic driver to the mainline is by rewriting half for the driver to make it use the mainline framework insteed of amlogic framework .
<chewitt>
lucastanure the T7 platform (A311D2) does not use the same HDMI driver (dw-hdmi) or USB (dwc2/3) as previous boards
<chewitt>
and the long-term challenge with Amlogic 5.4 kernel sources is, Amlogic has their own 'DRM' architecture
<chewitt>
so there is working reference code in vendor kernel sources, but it's not something that can be easily transposed into the upstream kernel
<chewitt>
USB will be easier
<chewitt>
as that's following an existing kernel framework
<narmstrong>
lucastanure: T7 has a new HDMI tx IP, so the upstream driver won't work
<chewitt>
as I currently understand it, T7 is an evolution of the S4 platform which is (very) slowly seeing core board support added
<narmstrong>
lucastanure: you're welcome to do the T7 upstreaming!
<chewitt>
the Amlogic engineers who are submitting things are not too familiar with kernel standards for code though
<chewitt>
so each submission requires careful review and requests for changes
<narmstrong>
lucastanure: first you should try to have a minimal (uart only) DT support, then push the clock & pinctrl drivers, then you can enable all the non-multimedia devices
<narmstrong>
the display support usually comes last, because it's the most complex
<narmstrong>
the S4 clock is still in dev and you'll be able to use it as reference
<narmstrong>
for pinctrl, it's quite easy to use the vendor one and adapt to upstream
<HackerKkillinghi>
btw Amazon Fire TV Cube 3gen use Amlogic POP1-G which the same as the Amlogic A311D2 processor that we reviewed in Khadas VIM4 SBC.
<HackerKkillinghi>
*almost the same as the Amlogic A311D2 processor that found in Khadas VIM4 SBC.
<f_>
Sure, but what about a list of devices with known RAM chips and FIPs?
<chewitt>
feel free to compile one and post it somewhere
<f_>
One of those FIPs may probably, PROBABLY work on the KII Pro......
<f_>
Speaking about FIPs and U-Boot...
<f_>
I think it's quite risky to do all this on the eMMC.
<f_>
You told me that I can disable it entirely and thus make the SoC boot from an SD card by shorting some pins.
<f_>
Can you please tell me which ones?
<chewitt>
it's not risky if you have a backup of the emmc and understand the process
<f_>
Well.
<f_>
Of course I'll backup the eMMC.
<chewitt>
unfortunately 99% of people don't understand, and it's fiddly
<f_>
Since I now have access to postmarketOS on it, backing up should be as easy as...........`dd if=/dev/mmcblk0 of=emmc_backup.bin`, right?
<chewitt>
if you flash a bad image and don't have either an HDMI dongle or SDIO board to force boot modes from
<f_>
I do not have a HDMI dongle.
<chewitt>
the fall-back is to short pins on the emmc chips to disable it and allow boot from an SD card
<f_>
Yes, but which ones?
<chewitt>
understandably, most users get scared of that
<chewitt>
yes, backup with dd
<f_>
Honestly, as long as I back up the eMMC.....should be fine.
<f_>
chewitt: Sure.
<f_>
I'll also backup boot0 and boot1.
<chewitt>
you need to boot from SD card though to ensure emmc is not in-use when you backup
<f_>
Yeah.
<f_>
postmarketOS is on an SD card.
<f_>
But wait.
<f_>
Isn't the vendor U-Boot loaded from the eMMC?
<chewitt>
yes, but once you hand-off to Linux it's not being actively used
<chewitt>
or at least, I never had issues with that
<f_>
Thanks!
<f_>
Will backup the eMMC.
<f_>
It's only 16GB, so that shouldn't be too much of a hasle.
<f_>
And then, copy the eMMC backup to the computer.
<f_>
Well. Somewhere safe.
<chewitt>
If you lookup the RAM chips in the box, you can cross-reference to reviews on cnx-software and 4pda forums
<f_>
Heh
<chewitt>
to see if they match with any of the devices with known FIPs in the LE repo
<f_>
I thought CNX-Software was one of those blog spam websites?
<chewitt>
no, cnx is a trustworthy and reputable source
<f_>
Nice!
<chewitt>
even if you find a match with RAM chip part numbers there is no guarantee the FIPs will work
<f_>
Of course.
<chewitt>
as cheap box manufacturers frequently use low-bin parts
<f_>
It's not only the RAM chip, is it?
<chewitt>
and 'name' box vendors tend to use better parts
<f_>
Is Videostrong a 'name' box vendor?
<chewitt>
acs.bin contains ram timing data
<chewitt>
Yes/No
<chewitt>
WeTek boxes are made by Videostrong
<f_>
a
<chewitt>
(according to the schematics I have)
<f_>
So the WeTek Play2 is just a rebranded KII Pro?
<chewitt>
but it depends on who commissioned the box and what design decisions they made
<f_>
(I've seen WeTek Play2 ROMs working on the KII Pro)
<chewitt>
so maybe, but maybe not
<chewitt>
roll dice and experiment
<f_>
chewitt: Speaking of schematics..do you have some for the KII Pro?
<chewitt>
no
<f_>
Ok
<chewitt>
and there are 30+ boxes that claim to be a kii pro
<f_>
That's not that much of a big deal.
<f_>
Popular devices also have clones that claim to be the real thing.
<f_>
And one more thing
<f_>
Is it possible to flash the eMMC backup by using Amlogic's proprietary flasher?
f_[xmpp] has joined #linux-amlogic
<f_>
chewitt: Also.....How do I disable the eMMC entirely?
<f_>
Which pins do I have to short?
<f_>
Ok. Dumping eMMC contents.
<f_>
I think boot0 or boot1 contain U-Boot (+ the FIPs, etc...)
<chewitt>
Amlogic Burning Tool uses an .img file but it has a different format to a raw dd .img file
<f_>
Ok. Good to know.
<f_>
What about Amlogic's `update`?
<chewitt>
there are some packer tools for their format in GitHub somewhere, but I haven't used them and can't remember exactly where right now
<f_>
Sure.
<chewitt>
update is also not a dd image
<f_>
Ok.
<chewitt>
and for pins .. I also forget but normally just get a screwdriver and short stuff until I find the right ones
<chewitt>
so far I got away with that
<chewitt>
(so far)
<f_>
Looks quite risky to say the least..
<chewitt>
indeed
<f_>
So I'll just look that up and document that.
<f_>
I'll upload the dumps too.
LucasTanure has quit [Quit: Leaving]
<f_>
I got something funny to share though.
<f_>
My KII Pro's CPU temperature is 7730941163F...
<f_>
lol
<f_>
Done.
<f_>
Hey look
<rockosov>
narmstrong: I saw some information about linux-meson SoC upstreaming status table a couple messages above. I can update that with our activities for A113L (a1 SoC family).
<f_>
But now we now which version their U-Boot is based on..
<f_>
*know
<f_>
We know which version their U-Boot is based on..
<f_>
As expected. 2015.
<narmstrong>
rockosov: sure, you can provide patches or a public tree pull request and I'll merge those
<f_>
Hi narmstrong
<narmstrong>
f_: hi!
jacobk has quit [Ping timeout: 248 seconds]
<rockosov>
narmstrong: Do you have any process to verify that new driver or hotfix patch series is workable and was tested by submitter on the real board?
<rockosov>
narmstrong: I'm asking not because of my curiosity :-) We have faced with several drivers from amlogic engineers which are not workable at all or partially... For example: A113X meson nand driver and A113L USB patch series
<rockosov>
I know it may be a quite difficult to check during review, and no idea how it should be, but anyway...
<narmstrong>
rockosov: no, it's only review, trust and CI testing on rc kernels
<narmstrong>
rockosov: on common SoC and board, we have great CI coverage, but for less used onles like A113D, it's only review & trust
<rockosov>
narmstrong: On the CI side do you check 'boot to shell' only? Or some more intricate scenarios?
<narmstrong>
rockosov: kernelci does some advanced smoke tests on peripherals, and some labs does advances 3d tests with mesa
<rockosov>
narmstrong: Could you please advise good point to understand current status and architecture of meson CI coverage?
<narmstrong>
rockosov: the main CI coverage is over kernelci.org using lava labs in different companies, there's also coverage from maintainers that run tests over different CI projects you can find on https://qa-reports.linaro.org/, and then some labs does their own Ci like samsung
<narmstrong>
there's no unified stuff, but most of it uses LAVA to driver the boards
jacobk has joined #linux-amlogic
<narmstrong>
you can participate and add your board to kernelci and report tests
<rockosov>
narmstrong: It's a good idea. But a main question is board physical location. Should it be placed in my infrastructure and has public IP address, right?
<narmstrong>
rockosov: the LAVA instance should be public so kernelci can submit jobs, but you can "hide" the actual LAVA managing the boards in your private infrastructure as a remote lab where you can run your private test jobs
<narmstrong>
the ide is that you will provide an user + token for kernelci, and them kernelci would provide an user + token to get the results of the test jobs on your lab
<narmstrong>
then you tell the kernelci admins your boards you have, and what tests you can accept
<rockosov>
narmstrong: Okay, got it. Is it possible to contribute new test suites to kernelci? For example for my board or vim3 or whatever