<dlan>
jbrunet: I'm confused about your 'two new line' comment (regarding reviews of the clkc ao patch), do you want to me to make sure files are always ended as "echo " instead "echo -n" ? the extra blank new line is actually not necessary in my opinion..
Elpaulo_m has quit [Ping timeout: 256 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 255 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 260 seconds]
Barada has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
indy has quit [Ping timeout: 264 seconds]
Elpaulo_m has joined #linux-amlogic
cthugha has joined #linux-amlogic
ldevulder has quit [Ping timeout: 268 seconds]
a5m has joined #linux-amlogic
<narmstrong>
dlan: Look at the end of the patch email :
<narmstrong>
2.15.1
<narmstrong>
--
<narmstrong>
+
<narmstrong>
+#endif
<narmstrong>
The extra "+" empty line should not be there.
<lissyx>
hm
<lissyx>
narmstrong, is there some magic write-protection somewhere ?
<lissyx>
received my six boards, and I'm having issues with at least one of them, constantly boots with filesystem error
<narmstrong>
lissyx: it should not
<narmstrong>
lissyx: is there an error around the sdcard detection ?
<lissyx>
and then root@ds-lepotato-1:/home/lepotato# mount -o remount,rw /
<lissyx>
mount: cannot remount /dev/mmcblk1p1 read-write, is write-protected
<lissyx>
narmstrong, it's not the sd card for sure, it works well in the other board I had for a few months, and I also swapped sd and still the same
<lissyx>
narmstrong, what kind of error / output should I look for?
<lissyx>
narmstrong, sure sdcards can be crap, but those are not
<narmstrong>
lissyx: ah ah, you cannot be sure of that ! never !
<narmstrong>
lissyx: can you dump the "mmc0: new high speed SDHC card at address 59b4" similar line ?
<lissyx>
narmstrong, it's SanDisk Extreme Plus, not noname-shit :)
<lissyx>
narmstrong, on the other board, exact same mmc0 errors
<lissyx>
oh mmc0 is the eMMC on-board
<lissyx>
sdcard is mmc1
<lissyx>
narmstrong, [ 1.919481] mmc1: new ultra high speed SDR50 SDHC card at address e624
<lissyx>
narmstrong, [ 1.897805] mmc1: new ultra high speed SDR50 SDXC card at address aaaa
<lissyx>
SDXC is currently installed in the new board, I swapped the SDXC/SDHC between boards, same behavior
<narmstrong>
It's SDR50 the issue
<narmstrong>
the timings behaviour depends on the board quality, and should not have passed the timings calibration
<narmstrong>
you should ask jbrunet for that...
<lissyx>
narmstrong, what do you mean? my boards are wrong?
<narmstrong>
the simple hack is to disable the sdr50 capability on this particular board, but it's a hack
<narmstrong>
lissyx: boards can be wrong, very easily
<lissyx>
narmstrong, like they should be sent back?
<narmstrong>
you have issue on only one board ?
<lissyx>
narmstrong, on one of the new boards I received
<lissyx>
narmstrong, the one I got during kernel recipes is fine
<jbrunet>
lissyx: Could you try to remove :
<jbrunet>
sd-uhs-sdr50;
<jbrunet>
sd-uhs-sdr25;
<jbrunet>
sd-uhs-sdr12;
<jbrunet>
from the libretech board dts
<jbrunet>
The error about mmc0 is expected if you don't have it ... maybe we should disable this node by default and let u-boot enable if the eMMC is present.
<jbrunet>
Still, nothing to be concerned about
<lissyx>
yep I figured so
<lissyx>
jbrunet, narmstrong, both boards shows SDR50, and yet only one boards gets faulty :(
<jbrunet>
The fs issue with sdr50 are more troubling ... To be honest, we initially target sdr104 on this board but had to scale down because of similar issue at 200Mhz. Signal quality was good enough for it
<jbrunet>
but it looked fine at 100Mhz
<jbrunet>
(SDR50)
<lissyx>
and now it wrecked the filesystem for good :(
<jbrunet>
That being said, we are considering disabling SDR UHS because of another issue
<jbrunet>
To get out of UHS, we should reset the card (means bring card supply to 0V)
<jbrunet>
unfortunately, we can't do that as the card supply is not controllable
<jbrunet>
this may render the sdcard unresponsive on soft reboot
<dlan>
jbrunet: I introduced the '+' end of line at patch v6, I misunderstood your extra new line comment, and I'm sending out v7 now, hope it's the final..
mayorga has joined #linux-amlogic
<lissyx>
jbrunet, narmstrong, unboxing a new board, let's see ...
<jbrunet>
dlan: git should be warning you about those whitespace error when you are doing your commit
<jbrunet>
it is actually how I found them to begin with
<lissyx>
jbrunet, was there any change to the kernel in the last few days?
<lissyx>
jbrunet, the 4.16.0-meson64 I had a few days was good for sure
<dlan>
jbrunet: it end as I need to remove the end of extra new line, so the problem in patch v5 is that there is a extra new line at file drivers/clk/meson/meson-aoclk.h (not meson-aoclk.c), and your comment in patch v5 confused me
<lissyx>
and the first boot of the new board was on 4.14.xxx and showed no error as well
<dlan>
jbrunet: sounds a good idea, I need to put checkpatch.pl into pre-commit git hook, which previously I didn't do that
<lissyx>
narmstrong, jbrunet, second unboxed board shows the same bad behavior :( :(
<jbrunet>
dlan: both your v5 and v6 had whitespace error. v5 was missing one, v6 had too much. This error are given when you commit by git, no special config for this. That being said, running checkpatch on every patch sent to the list is highly recommended
<jbrunet>
You can be sure I'll run it before accepting any
<jbrunet>
lissyx: changes regarding mmc ... I don't think anything worth mentioning, but I could be wrong
<jbrunet>
lissyx: what is the 4.16.0-meson64 BTW ?
<lissyx>
Linux ds-lepotato-1 4.16.0-meson64 #15 SMP PREEMPT Thu Apr 5 16:51:35 CEST 2018 aarch64 GNU/Linux
<lissyx>
jbrunet, armbian latest uptodate
<lissyx>
jbrunet, but changing the dts, I need to rebuild it after, it's going to be pain
<jbrunet>
you could also remove the property
<jbrunet>
before booting
<jbrunet>
in u-boot
<lissyx>
I don't even know how to access uboot
<lissyx>
jbrunet, with 4.14 kernel, no ext4 corruption but some messages in dmesg
<jbrunet>
u-boot is the funny thing showing up on the u-art before the kernel do
<jbrunet>
do you have the uart hooked up ?
<lissyx>
nope
<lissyx>
jbrunet, so far, 4.14 image an dtb, no more issue at all
<lissyx>
wtf
<lissyx>
now the 4.16 kernel also behaves erratically on the old board
mayorga has quit [Ping timeout: 256 seconds]
<lissyx>
jbrunet, I'm sorry, I don't have much time to play right now, so I'll setup my six boards with stable kernel and not the -next one
<jbrunet>
lissyx: +1
<lissyx>
jbrunet, but if it does reproduces indeed also on the older board, I might be able to investigate that
<lissyx>
no error at all after full apt upgrade, installing docker and nodejs, running docker helloworld
<lissyx>
and now running some npm install
mayorga has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 255 seconds]
<lissyx>
jbrunet, narmstrong, the two new boards are online on taskcluster and running tasks properly, no issue at all regarding microSD / FS with the 4.14.32 kernel
<lissyx>
that's good :)
<Ely>
Been using SDR50 on my potato, no issue to report, even with reboots.. Obviously this doesn't mean much as it's only one board/sdcard.
<lissyx>
I did benchmarked the board with the sdcard for some time, and no issue either before
<Ely>
lissyx: sdr104 also works well when adding it to dts, and I'm on 4.17-rc2. What's your sdcard model ?
<lissyx>
Ely, SanDisk Extreme Plus 64GB
<Ely>
kk, mine is a SanDisk Extreme PRO 32 GB
<lissyx>
I had a few Extreme Pro, but benchmarks were shitty
<Ely>
oh ? I believe pro is supposed to perform better than plus (iirc.. sandisk's namings are pretty confusing)
<Ely>
ah nvm about sdr104, it won't boot with max freq. 200MHz.
afaerber has joined #linux-amlogic
<jbrunet>
I tried a dozen sdcard from different manufacturer, most perform well in sdr104 ... but some brand could not handle it ... while working with other HW
<jbrunet>
We can't enable it if is not 100% stable.
<jbrunet>
regarding the reboot, it is real issue th
<jbrunet>
that has been reported and I have reproduced it
<jbrunet>
Could not find a solution yet ... maybe later
<jbrunet>
Of course, if you know what you are doing, you are free to enable any mode you want ;)
cthugha is now known as ldevulder
<Ely>
jrbunet: Your patches to remove SDR definitely won't stay in my local tree :-)
<Ely>
Thanks for filling in the commit descr. btw, will think about it next time
<Ely>
narmstrong: So, we can't do HEVC 10-bit without using Amlogic's frame buffer compression pixfmt. I'm thinking of adding the "AMLC" fourcc for this purpose.. Are there words about "losless compression" or "frame type compressed" in AML DRM ?
vagrantc has joined #linux-amlogic
<jbrunet>
Has I said previously, you can alter the device tree in u-boot ... so don't need to modify the source. I can just add or remove properties before booting linux
Barada has quit [Quit: Barada]
<narmstrong>
Ely: for DRM you will add a modifier for this vendor specific format
<narmstrong>
same for an eventual 32x32 tiled format
<narmstrong>
xdarklight: \o/ Arnd pulled the USB DT as fixes !
<narmstrong>
🍾 !
a5m has quit [Remote host closed the connection]
sputnik_ has quit [Remote host closed the connection]
<Ely>
xdarklight: congratz! Been testing out your USB work on Le Potato, works great.
<Ely>
narmstrong: Thanks. When glancing in AML DRM code, did you come across code specific to "lossless compression" ? (that's how they reference it in the decoders code)
<narmstrong>
Yes
<narmstrong>
They use the same name as ARM
<Ely>
Ah right! I remember you saying this already.
<ndufresne>
isn't the compression AFBC ?
pionen has joined #linux-amlogic
<Ely>
It's a "proprietary solution that resembles AFBC but is incompatible with it" - their words.
<Ely>
But maybe their display IP also supports AFBC to work with the MALI ? I really don't know :/ .
<ndufresne>
well, that strange, making it incompatible with the GPU, by choice ...
<ndufresne>
but we'll never be able to check, since AFBC format is a secret
<Ely>
They don't leverage the GPU on their video frames, they're sent right away to the display
<ndufresne>
which is a bit .. unflexible
jakogut has joined #linux-amlogic
<narmstrong>
They also support AFBC because they have a Midgard gpu on S912 ;-)
<narmstrong>
But did someone reverse engineered the afbc format ?
jakogut has quit [Remote host closed the connection]