Barada has quit [Remote host closed the connection]
return0e has quit [Ping timeout: 244 seconds]
return0e has joined #linux-amlogic
<narmstrong>
ndufresne: yet it can, look at the u-boot cmdline prompt (q200 or q201) and the equivalent ref design board we pushed upstream should work
ldevulder_ is now known as ldevulder
mastertheknife has joined #linux-amlogic
Amit_T has joined #linux-amlogic
LeosSire has joined #linux-amlogic
<LeosSire>
Good morning all, I have come from an OpenwRT development back ground and have moved to trying to develop a solution for a S905x A95 Nexbox unit.
<LeosSire>
I have cooked image and am now stalling. Is the system supposed to hang after "Starting kernel... uboot time: 62691200 us" as there is no root file system, or is my system not loading properly?
sputnik_ has quit [Remote host closed the connection]
sputnik_ has joined #linux-amlogic
sputnik_ has quit [Remote host closed the connection]
return0e has quit [Ping timeout: 272 seconds]
ndufresne has quit [Ping timeout: 252 seconds]
Amit_T has quit [Quit: Leaving]
return0e has joined #linux-amlogic
ndufresne has joined #linux-amlogic
<narmstrong>
LeosSire: did you # setenv bootargs "console=ttyAML0,115200" ?
<ndufresne>
mjourdan, looks like tiling works indeed, I'm still worried there might be a UV shift, in the title of bbb, there is some green pixels ont the edge of the blue letters, it's not that visible, a pixel diff from a reference decoder (like JM) would tell use more
<ndufresne>
mjourdan, about the seeks, it will be important to look at it, since couple of seeks often cause "Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010"
<mjourdan>
ndufresne: thanks for all the info about the gst player
<mjourdan>
About that UV shift, is it with hevc as well ? What is your bbb file encoded with exactly ?
<mjourdan>
EOS is a bit hit and miss sometimes.. Although H.264 and HEVC should be the most stable with it (unless you go crazy with seeking)
<mjourdan>
Thanks for the dump, I'll try to reproduce
<ndufresne>
the shift that I observed was currently with HECV, a file i found on the internet, bbb-1920x1080-cfg02.mkv
<ndufresne>
I still didn't took the time to increase the CMA, so I test with 1080p
<ndufresne>
mjourdan, for MPEG2_03_576i_50_AC3-transformers.ts, it seems to play fine, the positionning of the plane is wrong, but I'm just running some WIP patch
<mjourdan>
That was fixed recently, it was a bug in the drm driver. @narmstrong force pushed his WIP patch with the fix included.
<narmstrong>
Always my fault !
<mjourdan>
:-P
Amit_T has joined #linux-amlogic
<mjourdan>
ndufresne: I just decoded bbb-1920x1080-cfg02.mkv and dumped the raw frames, there's no sign of greenish pixels, I think it happens later.
<mjourdan>
I can somewhat see tealish lines near some letters, but they're also there in the original sample
<Amit_T>
Hello: I am trying to upstream s905 support in ATF and in the process I could boot Mainline Linux(with only single CPU) with mainline bl31.bin.
<Amit_T>
but now I need to bring up other cores for SMP boot.
<Amit_T>
Can anyone please let me know the exact sequence of secondary core bring up for s905?
<Amit_T>
narmstorng: other day, you mentioned it could only be done from SCP but I was wondering why is it so ?
<Amit_T>
on Allwinner , we can access the peripheral from SCP as well as from Coretex A53 cores, why is it not possible for S905 ?
<narmstrong>
because it's secure ;-)
<Amit_T>
but , I believe from EL3 you could access every secure device no matter you are on application processor or SCP
<narmstrong>
SCP has some specific registers you can't access from EL3
<ndufresne>
mjourdan, i've capture some frames, converter to RGB -> PNG using GStreamer, what I see comes out green on the screen, comes out dark pixels
<Amit_T>
for instance, would you like point to which registers.
<narmstrong>
how would I know ?
<ndufresne>
mjourdan, anyway, there is difference between ffmpeg result and amlogic result, but nothing major, I'll blame something else, probably somewhere in the drm driver, or qv4l2 (since I'm currenlty using a HDMI capture device)
<Amit_T>
ok
<ndufresne>
mjourdan, yeah, visually, it comes out identical if I use avdec or v4l2
<narmstrong>
Amit_T: why don't you communicate with the SCP ?
<Amit_T>
yeah
<narmstrong>
Amit_T: it's actually here for a reason....
<Amit_T>
I tried it with no success
<Amit_T>
but just to do CPU on/off from SCP make very less sense
<mjourdan>
ndufresne: I test with "ffmpeg -c:v hevc_v4l2m2m -i bbb-1920x1080-cfg02.mkv -an out.mkv" , simple HW decode + SW re-encode. Output is fine so it's definitely somewhere else :< .
<narmstrong>
it's more than CPU on/off, it also managed the power state and the power rails as defined in the bl301
<narmstrong>
note that the SCP waits the bl30 and bl301 to be loaded before is will answer
<narmstrong>
the bl301 defines how the platform handles the power rails and the supported cpu freqs
<LeosSire>
@narmstrong, you mentioned running #setenv bootargs "console=ttyAML0,115200"; I have done this and it makes no difference.
<narmstrong>
LeosSire: well, can you give us much more details on how you start your kernel
<mjourdan>
ndufresne: I'll check with a screen, to see if it happens via the display path
<ndufresne>
mjourdan, I'll need to connect directly to my screen first, to see if it's qv4l2 or my capture card
<Amit_T>
narmstong : Actually I tried to look in to bl30.ef provided by cyrozap, https://paste.ubuntu.com/p/Nq6TrfwCqk/ . Can you see fuction that may on/off the CPUs?
<narmstrong>
Amit_T: I suspect it will be handled in amlogic_mb_receive_secure, no idea what if the symbol called
<narmstrong>
amlogic_mb_receive_secure is the link used with EL3, high/low with linux/u-boot
<narmstrong>
LeosSire: sorry but you don't seem to change the bootargs here
<mjourdan>
ndufresne: looks okay with a screen as well (using mpv)
<LeosSire>
@narmstrong, apologies, thats was an old putty log. I have run it with changing the bootargs; literally just now again, to no avail.
<LeosSire>
@narmstrong, I would do anouther paste bin but the log has decided to put itself into chinese characters. I reckon the log is collecting 'fluff' along with standard output
<ndufresne>
mjourdan, the drm still does not do 4K right ?
tlwoerner has joined #linux-amlogic
<LeosSire>
@narmstrong, could it be the address '0x108000 - $dtb_mem_addr' if the dtb file is larger than that which was included in the orignal instructions
<narmstrong>
It will break with a Mali gl rendering
<narmstrong>
LeosSire: nop this line is ok
<LeosSire>
@narmstrong, and here was me hoping it was that easy.
<mjourdan>
ndufresne: With what you have now, you'll still be able to play 4K content, it'll get downscaled nicely. If you want 4K HDMI 1.4 modes, refer to @narmstrong ^
<narmstrong>
LeosSire: add earlycon to the bootargs
<ndufresne>
And that wasn't sufficient, but it's a bit of a bug in vdec, you seems to allocate 20 capture buffers
<narmstrong>
Yep 4K downscaling works and my 4K patch also works, but only 8bit output, no HDR
<mjourdan>
ndufresne: This patch is barely enough cma for 4K 8-bit (and don't go overboard with the buffer counts :D).
<mjourdan>
For 4K 10-bit I'd recommend 0x30000000 to be on the safe side
<ndufresne>
ok, I don't think this one is 10bit, it's the iphone capture you gave me a while ago
<narmstrong>
I’ll put 1gib to be sure ^^
<ndufresne>
what do you mean don't go overboard with ...?
<mjourdan>
Don't request like 16 OUTPUT buffers or something lol
<ndufresne>
I request 4, the driver gives me 20
<mjourdan>
When decoding 4K 10-bit and userspace requests NV12 8-bit, twice the buffers need to be allocated. One set for decode, one set for output. So ram usage goes sky-high :(.
<ndufresne>
I can't do anything about that
<mjourdan>
Oh yeah the CAPTURE is 20, indeed you can't do much about it
<ndufresne>
but according to the spec, there is no way you'll need 20
<mjourdan>
I need 16 for the DPB and 4 spare for whatever userspace does (like locking them with the display)
<ndufresne>
but I already told you this is wrong, you cannot hardcode in your driver what the userspace need
<ndufresne>
also, the DPB size is rarely 16
<ndufresne>
the headers will tell you which size it is, then you can implement the appropriate CID to let use know what was parsed as minimum, and userspace will add whatever it needs
<mjourdan>
I mean, I'll happily reduce it, but then userspace needs to handle figuring out the DPB size on its own and set the appropriate bufcount
<ndufresne>
well, speak with the Endless people, they where extrating this info form the hw parser before
<mjourdan>
For H.264 I know I can, for HEVC I'm not sure, let me check..
<ndufresne>
mjourdan, another thing that does not seem logical to me, is why you need to allocate that many twice
<ndufresne>
In coda, they have a converter, so they allocate the DPB for the decoder, and then whatever userspace request for the converter ...
<mjourdan>
the double alloc is only in the special case where you decode 10-bit but request a 8-bit format like NV12
<mjourdan>
in all other cases only one set of buffers is used
<ndufresne>
ah ok, didn't get that one
<LeosSire>
@narmstring; from printenv it is currently earlycon=aml_uart,0xc81004c0
<ndufresne>
mjourdan, I'm just going myself the reflection, since on the Xilinx I'm working on, which is also using CMA pool, we do 8 time 4K transcode, 10bit, with 1.5G
<ndufresne>
(not in all config, but the low latency one at least)
<LeosSire>
@narmstrong, what should I set it to if it's already present?
<ndufresne>
ok, 4K works, interesting that for this 4K file, it ends properly (it's not playing all frame, but it ends at least)
<mjourdan>
Seems reasonable if you use something like 6-8 capture buffers
<mjourdan>
Do you handle in gst the amount of additional buffers you need that are locked by dmabuf consumers ?
<ndufresne>
mjourdan, another reason it would be nice, is that startup time is quite slow (and get worst over time), which is likely caused by cma allocation
<ndufresne>
mjourdan, yes, in gst we negotiated the minimum number of buffers needed between two elements, and we take into account locked dmabuf like the scannout buffer, an encoder etc.
<ndufresne>
and we read the the part that the decoder needs in v4l2 using V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
<mjourdan>
okay
<mjourdan>
I'm guessing you rely on the src change event before probing that control
<ndufresne>
not at the moment, but you can assume that yes
<ndufresne>
this event did not exist when I wrote this code
<LeosSire>
@narmsrong, could it be that I'm using a USB instead of a mmc, as you can see the BL registers the USB stick and the images on it.
<mjourdan>
ndufresne: so, you start a capture with a default amount of buffers, wait for the first dqbuf, and then probe it ?
<mjourdan>
and then you restart the decoding sequence all together ?
<ndufresne>
mjourdan, so the current flow is approximatively reqbuf(out), qbuf(out), streamon(out), G_FMT(capture), and then we read that control
<ndufresne>
the output and the capture are not set to streamon() at the same time
<ndufresne>
basically, gst relies on a G_FMT blocking on the parsing of the headers, this Tomas have decided to drop, which I agree, it's quite ugly
<mjourdan>
It's risky to assume you can get anything with only one queue initialized
<mjourdan>
I know the venus driver needs both queues streamon before doing anything
<mjourdan>
ndufresne: so, I could do the src change event as well as the min capture buffers properties. But only for H264 and HEVC. I guess this would make it optimal, and follow Tomas' spec.
<mjourdan>
However, older codecs like mpeg2/mpeg4 need a fixed amount of buffers no matter what and start decoding into buffers as soon as you queue something in the parser.
<ndufresne>
mjourdan, not sure who told you that, but the venus driver works fine if userspace streamon the output, passed headers, and later streamon the capture
<ndufresne>
It's also going into the spec
<ndufresne>
mjourdan, about the other codecs, that HW specific, I'd say just expose this number in the proper CID, telling userspace at REQBUF time isn't very usable
<mjourdan>
my bad then. I based a lot of code from the venus driver, and noticed that it needed both streamon_cap and streamon_out to actually start streaming, but I must have missed something
<ndufresne>
maybe you forked before it worked with GStreamer ;-D
<ndufresne>
I've worked very closely with Stanimir to get this running in kmscube
<ndufresne>
the venus driver still need a lot of work btw, it does not really survive a resolution change as an example
<ndufresne>
everything works in fact, but the output after the change is solid green ;-D
<ndufresne>
mjourdan, also, the discussion I'm having with you, I also had the same last year with stanimir
<ndufresne>
(there is so many discussion going in fact ...)
<ndufresne>
mjourdan, ok, that's starting to look good, if we could get seek and eos, we'd be on par with the majority of drivers
<ndufresne>
I haven't tested h263, and mpeg4 yet
<mjourdan>
hehe yep, it's still very moving
<mjourdan>
ndufresne: I just got chromium working at this very instant with meson-vdec, so it's promising since it uses src change event & co (I've been hacking it together for H.264 to see if it was possible).
<mjourdan>
I'll keep you updated when I push such support
<mjourdan>
ndufresne: I'll definitely work on seeking to see what's going on.. It's a painful thing to handle :P
<narmstrong>
mjourdan: cool ! It can be a third demo !
<mjourdan>
narmstrong: yep! Now I need to make sure nothing happens to that sdcard :D
<narmstrong>
Dump it and send us a copy ^^
<narmstrong>
mjourdan: is it smooth ?
<mjourdan>
it's not 60fps no :( . It's 10x smoother than sw decoding but not kodi-smooth
<mjourdan>
might be related to scaling, I don't know how chromium does it since they use egl/drm on the primary plane
<mjourdan>
like what lrusak did on kodi before we had the overlay plane
<narmstrong>
They use gl, it won’t do miracles unless using the overlay plane...
<narmstrong>
But on wayland it’s far from being solved :-/
<narmstrong>
VLC should work, no ?
<mjourdan>
I have no idea, and no time to test it this week
<narmstrong>
It could be the fourth demo !
<mjourdan>
lol
The_CooIest has quit [Ping timeout: 252 seconds]
The_CooIest has joined #linux-amlogic
bengal has quit [Ping timeout: 252 seconds]
bengal has joined #linux-amlogic
<Amit_T>
narmstorng: Just didn't get your point here, amlogic_mb_receive_secure is the link used with EL3, high/low with linux/u-boot ?
<mjourdan>
ndufresne: the only way I could see this work is if you do a streamoff/streamon in between each change, since there's no support yet for dynamic resolution changes
<ndufresne>
that's what I do in gstreamer
<mjourdan>
that explains it :P
<ndufresne>
though, I'm not sure if it's resolution, or bitrate
<ndufresne>
probably resolution
<mjourdan>
dash is usually both
<mjourdan>
bitrate changes are rarely a problem
<ndufresne>
right, so one would need to figure-out which glitch match which change ...
<ndufresne>
(nevermind, it probably requires the missing mechanism your refer to)
<ndufresne>
to work smoothly, you'll probably need to figure-out how to keep the largest allocated buffers and get these to be reused when resolution goes down
<mjourdan>
Yeah that's a good point. I think it's what the venus driver does, if the current buffers are large enough, the src change event isn't even sent
<mjourdan>
although I wonder how do you pick up from userspace that resolution went down for example
<ndufresne>
hmm, if you don't send the event, the userspace won't know, and rendering will be odd
<ndufresne>
I think you send the event, but use the bytesperline (stride) and sizeimge to match the original allocation
<ndufresne>
actually, we don't care about the stride
<ndufresne>
just keep the sizeimage, userspace can compare the sizeimage from the new format against the sizeimage of the allocated format, and skip REQBUF
<ndufresne>
Hans also added today a block that says you always need to streamoff/streamon the capture after this event