<gdeverlant_>
does anyone already used it or knows about it
<gdeverlant_>
is this going to replace u-boot ?
default__ is now known as ldevulder
AUser has quit [*.net *.split]
filt3r has quit [*.net *.split]
<narmstrong>
gdeverlant_: it is implemented in u-boot right now and available using mainline u-boot for Odroid-c2 libretech-cc nanopi-k2 and khadas vim
<narmstrong>
It already works, you can boot the OpenSuse or Debian EFI installer directly
gdeverlant_ has quit [Ping timeout: 240 seconds]
gdeverlant_ has joined #linux-amlogic
<gdeverlant_>
any one have any idea ?
AUser has joined #linux-amlogic
filt3r has joined #linux-amlogic
<ldevulder>
gdeverlant_, idea about ebbr? narmstrong just answers you :) but as you have disconnected maybe you didn't see it
<gdeverlant_>
yeah i got disconnected
<gdeverlant_>
let me check the logs
<ldevulder>
:)
<gdeverlant_>
ohhh wow
<gdeverlant_>
does it mean that I can just install with an iso USB from debian
<ldevulder>
yes
<gdeverlant_>
boot in the usbstick and install just like that
<gdeverlant_>
the distros like windows on the arm board ?
<ldevulder>
any Linux distro that support EFI boot an arm64
<ldevulder>
windows arm not sure
<gdeverlant_>
no i meant doing an install like when you insert the windows cd
<gdeverlant_>
but on arm with linux
<ldevulder>
yes
<gdeverlant_>
without needing goign through the pain of compiling your own kernel and blablabla
<ldevulder>
as narmstrong said it works for debian and opensuse
<ldevulder>
don't if other distros have been tested
<gdeverlant_>
how does it work specifically ?
<gdeverlant_>
you still need to flash an sd or mmc card
<gdeverlant_>
so that uboot at least exist somewhere ?
<ldevulder>
you still need to flash u-boot somewhere
<ldevulder>
sd, emmc or spi
<ldevulder>
(spi is better if you have one!)
<gdeverlant_>
i don't kow spi sorry
<ldevulder>
and then boot with iso on usd for example and try 'runsub' on uboot cli, and installer will start like on a x86 desktop/server :)
<gdeverlant_>
i can only afford microsd
<ldevulder>
spi is flash device directly on the board, generally small (between 2/4MB to 128MB, it depends) and mainly used to store the bootloader/kernel
<ldevulder>
the khadas vim2 board has one for example
<gdeverlant_>
ohh ok i get but odroid c1/c2 doesn't have something like that
<narmstrong>
no c1/c2 does not, but you can flash u-boot on the sdcard and install the system on mmc for example
<gdeverlant_>
well it is practical
<gdeverlant_>
this will make arm so much more accessible for normal people
<ldevulder>
narmstrong, regarding emmc one short question: do you know where I can buy some at a good price? and from France of course :D I quickly checked but it's not so easy to find (I mainly had a look on Amazon)
<ldevulder>
gdeverlant_, definitely yes :)
<gdeverlant_>
you can buy good ones from www.pollin.de
<Darkmatter66>
putting the brcmfmac4335-sdio.txt file from the vendor source into the brcm directory causes errors in dmesg https://0x0.st/sY38.txt
<Darkmatter66>
sometimes iw shows the wifi and sometimes not
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 252 seconds]
Darkmatter66 has joined #linux-amlogic
<brads>
if I apply realtime patches, high res timer+ and a few different usb audio devices on the C2 performance is ok for playback or capture but not both at the same time, 2 irq threads demanding the same interupt both the 4 port host only driver and also the root controller driver, they seem to be in a race at times. Can the dwc2 be improved in this regard or maybe its simply a hardware
<brads>
limitation? I can probably use usb input ok (connected to 4 port hub) and HDMI (or i2s) output for playback channel.
<brads>
I can work around it setting cpu affinitys and 2 seperate usb sound cards (one playbakc only + 1 capture only)
<brads>
I want low latency audio, ie < 22ms in and out (with A53's) acting as dsp
<brads>
maybe I need to wait for c2 sound card driver for i2s for duplex
<wens>
Darkmatter66: the nvram files aren't in the official linux-firmware repository, therefor it's unlikely you'll find them in distro firmware packages
<wens>
Darkmatter66: btw, shouldn't the vendor provide you with the wifi firmware? it might not be the same name, in which case you should rename it so it matches
<Darkmatter66>
wens, the vendor provides the firmware files for the out-of-tree kernel (3.14.29) and not for mainline, anyway the firmwares are available from the linux-firmware tree, the problem is in the nvram.txt files
<Darkmatter66>
Has anyone been successful in getting a broadcom wifi chip working on these devices in mainline linux ?
<brads>
btw still looking at how to backport mutter wayland for libMali which is really a thorn in my side but others have suggested some compat libs instead of modifying mutter which sounds very promising. I still like the sound of lima but I dont have the skills to help develop so much although I would be happy to try learn. All I want is some low level GPU performance for the UI and low
<brads>
latency audio in and out. Vdec is a bonus and seems to work well for my limited use cases :) Realtime patches with usb audio are not a lot better than low latency stock but help to pin point the dwc2 drivers as the latency issue in my use case. 3.14 amlogic'ised hardkenrel kernel seems much worse for interrupt contention and latency thank any mainline release.
<brads>
I have a wifi contoller and I think it is broadcom based but does not seem to work on my C2 (or x64 in Linux) never looked at it further (hardwired now) but I will check on the weekend.
<Darkmatter66>
brads, do you mean a usb one ? I don't think this is the same situation, the problem is probably in the chips that are connected through SDIO
<brads>
ok sorry yes it is a usb BCM4323 based WNDA3100v2 Broadcom
<Darkmatter66>
I did notice that the wifi chip is activated on boot and I can see it using "iw" but if I do rmmod and then modprobe then the wifi doesn't show
<ndufresne>
mjourdan, just to let you know, I've given another round of test to your branch, it seems that stream switching (slow drain, followed by reconfiguration) seems much more stable, the H265 side seems more stable, on H264 dash adaptative streams, I often see a glitch on transition, though, hard flush, used for seeking does not work, the driver never restart
<mjourdan>
ndufresne: Thanks for testing! I fixed some nasties regarding drain for mpeg2 and h264
<mjourdan>
Can you expand on "hard flush, used for seeking does not work, the driver never restart" ?
<wens>
Darkmatter66: firmware doesn't matter if its for mainline or bsp, it gets loaded on the chip
<mjourdan>
Also, in the following days I'll be working on H.264/HEVC support for V4L2_EVENT_SRC_CH_RESOLUTION, V4L2_CID_MIN_BUFFERS_FOR_CAPTURE and vidioc_g_selection
<brads>
Darkmatter66: I think I even tryed emulating windows drivers on 64 linux and then gave up as it did not work out well with linux due to netgears windows only support. Its now dedicated to my windows 10 machine and works well.
<brads>
mjourdan: I will do some testing with the vdec on the weekend (I have been busy this week), I love what I see so far :)
<Darkmatter66>
brads, yeah broadcom is very bad at linux support, i disabled my laptop's built-in broadcom chip and use a realtek usb chip now since they have better drivers
sheepman has quit [Read error: Connection reset by peer]
<ndufresne>
@mjourdan, iirc hard flush is done by setting all queues to STREAMOFF, buffer/fmt will only be updated if the format changes, so most of the time (seeks), we will immediatly queue an input buffer, queue all capture buffer, and streamon(output/capture)
<ndufresne>
or something close to this
<ndufresne>
this fast flushing of the decoder state commonly trigger race in the drivers, probably because it's not a single call, but a combination of calls
jakogut has joined #linux-amlogic
<mjourdan>
brads: Thanks :) . Let me know if you have any question. The driver is still very new and userspace keeps evolving as well (the official spec to deal with a v4l2 m2m video decoder is still being refined), so you're bound to encounter some bugs..
<ndufresne>
mjourdan, I think next round, I'll test what happens whenever a frames is lost (rtp packet lost use case)
<mjourdan>
ndufresne: I see. This is something I should be able to reproduce with the gst plugin that allows you to seek from command line ?
sheepman has joined #linux-amlogic
<ndufresne>
mjourdan, should yes, gst-play-1.0 somefile, and then right arrow
<ndufresne>
if you need to look at the trace, you could do "space" (pause) and then right arrow
<ndufresne>
this will reduce the storm of traces
<ndufresne>
mjourdan, does seeking works with ffplay ?
<mjourdan>
I have never tested ffplay, so I don't know :/
<ndufresne>
ah, I see, what do you use then ?
<mjourdan>
The closest thing to "seeking" I got was from mpv, I think it just kept passing packets from the seek point without doing any kind of streamoff or anything
<mjourdan>
It worked okayish
<ndufresne>
right, well, not that bad, depends on the encoding really
<ndufresne>
this is how seeking works with RTSP as an example
<brads>
I did not get mpv to work but vlc and mplayer worked well
<ndufresne>
it's the server that seeks, the receiver just keep rendering, if you have a 2s receiver queue, it takes 2s to seek ;-D
<brads>
on console
<brads>
bring it wayland and egl and it went out the window (unless I had a second console :)
<brads>
I didnt check seek but fps was good
<mjourdan>
mpv is almost working great, the only problem is that for some reasons the timestamps passed to the v4l2 buffers are all 0
<ndufresne>
oh yeah, same here with gst/kms, playback performance is just excellent
<mjourdan>
that messes with the driver a bit
<brads>
I didnt have UI :( no wayland and display manager was cpu bound impacting performance
<ndufresne>
mjourdan, you mean timestamp are unset, you know these are optional for m2m codecs right ?
<mjourdan>
I don't think that point has been resolved yet
<mjourdan>
In my case it's mandatory because the driver/firmware doesn't generate pts on its own
<mjourdan>
then you have chromium v4l2, they use timestamp as a cookie that you *must* match from the src to the dst queue
<ndufresne>
it's weird, since in decoding, there is no use for time information
<ndufresne>
in encoding, you don't even need the TS, you just need frame duration to compute the bitrate
<mjourdan>
Well if you pass only 0 timestamps it will still work, you get the guarantee that the frames are in presentation order
<mjourdan>
but the dst timestamps will also be 0
<ndufresne>
which makes sense, and the broke with mpv ?
<ndufresne>
I guess we'll have to investigate
<mjourdan>
mpv relies on ffmpeg, and ffmpeg does its usual timestamp checking/frame dropping based on the frames' pts
<ndufresne>
I could probably write a quick test with TS set to 0 in gst, so see what happens
<mjourdan>
tl;dr: gst, ffmpeg, chromium all do different things with timestamps and have different expectations
<mjourdan>
and it's not resolved yet in the spec
<ndufresne>
on my side, I pass the gst PTS (so the timestamp in presentation time), I don't know if I use them yet, or if it's still in my todo, but it's only useful to identify which frame came out
<ndufresne>
This way, the driver can drop frames without any issues, as I'll be able to know and cleanup old frames wrappers
<ndufresne>
drivers can drop is it works in deadline mode (a bit like libvpx) or if the packet was corrupted, and it's skipping due to internal error
<mjourdan>
so you do use them :p
<brads>
S905 + mainline works well without dwc2 drivers loaded for low latency applications, I wonder how well vdec works without dwc2
<brads>
bring on the weekend so many things to test out
<Darkmatter66>
mjourdan, mpv is very sluggish for me, I can see from dmesg that the vdec is used but the playback is just slow
<ndufresne>
mjourdan, narmstrong: about the overlay patch, is the newly added black border intentional ?
adema has joined #linux-amlogic
<narmstrong>
black border ?
<Darkmatter66>
mjourdan, I applied the patch and used the last command you posted and the playback is slow and getting drops
<Darkmatter66>
mjourdan, do I need the libmali.so for this to work ? what version, I don't remember but I think the libmali I have setup is for X.org,maybe this is the problem ?
<ndufresne>
narmstrong, yes, when I play something to kmssink, it never there is always some black border around, it's never flush with the edges
<ndufresne>
looks like some 25% overscan
<ndufresne>
oh maybe it's a side effect of 1920x1200
<mjourdan>
ndufresne: Pretty sure that's a positionning bug that was fixed some time ago. @narmstrong forced push the fix to his branch so the commit I linked earlier should be up to date
<mjourdan>
Darkmatter66: can you copy/paste your mpv log just in case ? If it works with those parameters then your libmali should be fine
<mjourdan>
Darkmatter66: ohh and you need ffmpeg patches to enable zero copy, I forgot...
<mjourdan>
Lots of moving pieces and patches around, most are being mainlined in the various projects but it takes time
<ndufresne>
narmstrong, never mind, it seems to work in 1080p
<ndufresne>
mjourdan, I updated yesterday
<Darkmatter66>
mjourdan, ahh the ffmpeg patches is what I'm missing
<mjourdan>
Darkmatter66: You're like the third person to ask me how to get zero-copy video rendering, I should write a wiki page or something :D . There are so many patches that I'm bound to forget something everytime.
<mjourdan>
Darkmatter66: You can also use gstreamer 1.14, should work well and you don't have to worry about mpv/ffmpeg. Unless ndufresne has pending patches that are mandatory.
<Darkmatter66>
mjourdan, well the linux-meson.com wiki is very small, other similar projects like linux-sunxi.org has alot of pages and notes
<ndufresne>
narmstrong, mjourdan: Positionning seems to work fine now btw, fyi, gst-play-1.0 somefile --videosink="kmssink render-rectangle=<0,0,950,540>"
<mjourdan>
ndufresne: Mmh, weird. I tested various samples with weird resolutions and even non-square PAR, and it worked well since the hotfix.
<Darkmatter66>
mjourdan, last time I used gstreamer it didn't work either
<ndufresne>
mjourdan, no in 1920x1200 it's the dar that is non-square, but I was hitting a UVC issue, UVC don't report that properly, I'm not using a display but a HDMI capture
<Darkmatter66>
mjourdan, but I was missing the overlay patch maybe that's why, I will test it in a second and report back
<ndufresne>
mjourdan, there is also padding with MPEG2_03_576i_50_AC3-transformers.ts that mjourdan provided me, but I'm starting to think this is encoded like this
<mjourdan>
ndufresne: That file is 720x576 with a 16:9 DAR (so non-square PAR), the PAR should be reported correctly by vidioc_cropcap
<AntonioND>
i'd love to get feedback and see if this is actually working for other people
<Xogium>
AntonioND: open source instead of a binary blob ? Cool
<AntonioND>
yeah, nobody likes binary blobs
<Xogium>
what about the bin.hardkernel file ?
<AntonioND>
that's not a priority for me right now
<AntonioND>
after boot, only bl31 and bl30 are resident
<Xogium>
nah but I meant, what does it contains ?
<AntonioND>
tbh no idea
<AntonioND>
bl2 or bl1 ?
<Xogium>
bl1
<AntonioND>
it's hard to say
<AntonioND>
normally bl1 loads bl2, and bl2 loads the rest
<AntonioND>
but I haven't seen any print from bl1, at least that I can identify
<AntonioND>
there is that leaked(?) version of bl2 out there so we can guess
<AntonioND>
but bl1 no idea
<Xogium>
very impressive work, honestly, it's facinating
<AntonioND>
well, i have 2 raspis that I've given up on, so I have to focus my efforts into something that may actually become 100% open (if the RE drivers of mali become usable at some point)
<AntonioND>
and thanks :)
<Xogium>
yeah rpi boot up is even more convoluted
<Xogium>
booting up from the gpu ? What the actual fuck
<AntonioND>
well, the secondary cores are the arm ones
<AntonioND>
so it makes sense :P
<AntonioND>
the original videocores didn't even have arm cpus
<Xogium>
ugh, I see
<AntonioND>
but the binary blob is like 4 MB
<AntonioND>
that elf file
<AntonioND>
4MB of broadcom binary madness
<Xogium>
that is quite a big blob ain't it ?
<AntonioND>
by comparison, ~50 KB of bl31 with a lot of helpful asserts and a reference repository are child's play
<Xogium>
I bet
<Xogium>
now if only someone would make an open mwifiex driver lol
<AntonioND>
heh
<Xogium>
that would be super cool, actually if its ever done, the espressobin would no longer require any blob at all. The mwifiex_pcie blob is the only blob my router needs, the rest of the hw is entirely open
<AntonioND>
oh, marvell...
<Xogium>
yep
<AntonioND>
we have a few ports of marvell boards upstream
<AntonioND>
and the maintainer is really responsive
<Xogium>
they are weird, they sometime make things open and sometimes closed
<AntonioND>
but there are no open hardware docs...
<AntonioND>
yeah, it's weird
<AntonioND>
tbh having source code without docs is a bit like having a binary blob that you can read
<Xogium>
yeah
<Xogium>
in all case nothing else than the attached minipcie card requires a blob on my router and I'm glad about it lol one blob can be enough trouble as it is
<AntonioND>
heh
<AntonioND>
I was thinking about buying a chromebook with rk3399
<AntonioND>
now that panfrost looks like it's getting somewhere
<Xogium>
is it ?
<AntonioND>
so I've heard
<AntonioND>
you can use coreboot + open port of the trusted firmware + the rest of it is open
<AntonioND>
except for mali
<AntonioND>
in odroid, even with an open BL31, the code that runs in the SCP is closed
<Xogium>
of course, go figure. Its always mali
<AntonioND>
yeah
<Xogium>
I hate mali
<AntonioND>
it's impossible to find a stupid sbc without mali
<AntonioND>
or powervr
<AntonioND>
which is even worse
<Xogium>
technically it is, machiatobin has got an open x4 pci slot, which means standard graphics card can fit in
<Xogium>
x4 open is enough to fit in x16 sized things
<AntonioND>
yeah, but it's outside of my "buy that for fun" range
<Xogium>
yeah indeed. Still worth mentioning
<AntonioND>
i actually took a look at it because in my team we are looking for replacements for juno
<AntonioND>
we are trying hikey960
<vagrantc>
/12/12
<vagrantc>
heh.
<AntonioND>
but the scripts to flash stuff there are just ridiculously stupid
* vagrantc
waves
<Xogium>
:/
<Xogium>
well, hi there vagrantc ! :)
<AntonioND>
actually the mcbin looks really developer friendly
<Xogium>
even runs mainline kernel and u-boot
<Xogium>
contrary to the espressobin which still has trouble with mailine u-boot, let alone rebuild their own u-boot fork
<AntonioND>
and updating the firmware is just a matter of copying files
<AntonioND>
in the odroid c2 it's actually quite nice, a simple dd command
<AntonioND>
oh, the espressobin. the maintainer said he's preparing the TF to be upstreamed
<AntonioND>
so that's nice
<vagrantc>
yeah, the espressobin, while seeming to have a lot of nice features, is really frustrating to work with for the boot firmware/bootloader
<vagrantc>
the vendor ATF does nearly everything backwards from what other implementations do ... e.g. you embed u-boot into the ATF, rather than the other way around
<vagrantc>
for the espressobin
<AntonioND>
lol
<AntonioND>
well
<Xogium>
mcbin seems a lot more sane
<AntonioND>
that's the normal way actually
<AntonioND>
according to the design of the ATG
<AntonioND>
ATF
<vagrantc>
hopefully when they upstream it they'll get people insisting they do things more consistantly
<AntonioND>
that most people don't follow
<AntonioND>
nobody is actually consistent when the TF is involved
<vagrantc>
and they require a bunch of hard-coded utilities...
<vagrantc>
it's the only outlier i've encountered in that regard
<AntonioND>
most ports only have the runtime part of it (bl31) and only a few have the others, like marvell
<AntonioND>
so most of them load the TF as part of another stage
<AntonioND>
while marvel does it the other way around
<AntonioND>
which is the "official" way of doing it
<AntonioND>
or the way arm wants people to do it
<AntonioND>
but this is firmware, and everyone does whatever they feel like