<KREYREN_oftc>
<apritzel> and conceptually both U-Boot and the kernel should be independent in terms of display enablement -- i see hmmm
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
machinehum has joined #linux-sunxi
<MoeIcenowy>
gamiee: nope, I did a little for V831 previously, not V5
<MoeIcenowy>
KREYREN_: your config looks too minimal
<MoeIcenowy>
CONFIG_DRM_SUN4I seems to need to be opted in
<MoeIcenowy>
it does not have a default value (thus default no)
KREYREN_ has quit []
KREYREN_oftc has joined #linux-sunxi
<KREYREN_oftc>
MoeIcenowy, why sun4i? It says to be for the AllWinner A10 display engine while i am using A64 which is sun50i
machinehum has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
KREYREN_oftc: for Allwinner mainline, it's usually only saying the first encountering chip
<MoeIcenowy>
however, at least the TCON design of Allwinner SoCs are developed continously
<MoeIcenowy>
with A64 TCON still similar to A10 one
<MoeIcenowy>
so the driver is always called sun4i
<MoeIcenowy>
despite getting support for many new chips
<KREYREN_oftc>
i see
<KREYREN_oftc>
but as said the u-boot should work without any linux on the device too right
<KREYREN_oftc>
like the display
<apritzel>
KREYREN: well, as you have learned, getting the right .config is not trivial these days: there are just too many options
<apritzel>
KREYREN_oftc: you can grep for the compatible string in the drivers/ directory, then check the Makefile in that directory for the file you find, which tells you the Kconfig option
<apritzel>
for instance: git grep allwinner,sun50i-a64-de2\" drivers/
<apritzel>
which gives you drivers/bus/sun50i-de2.c, so you check drivers/bus/Makefile for sun50i-de2.o, which gives you CONFIG_SUN50I_DE2_BUS
<apritzel>
rinse and repeat for other compatible strings you need, and don't forget trivial things like CONFIG_REGULATOR_FIXED_VOLTAGE
<apritzel>
or you just go with what the distributions produce, they put a lot of effort into getting this right
<KREYREN_oftc>
apritzel, helpful thanks
<apritzel>
but you should ask yourself what you want to save: the Teres-I has 2GB DRAM, IIUC. With a modular kernel the size of the kernel shouldn't really be a problem then.
<apritzel>
and while you probably will eventually succeed with this exercise, this is just for one board, and one kernel version, and you probably still miss features, say for networking or whatever you want to run
<apritzel>
for instance systemd has some requirements, or if you want to run docker containers, and the list goes on
<KREYREN_oftc>
apritzel, i want to be able to recompile the kernel from the device itself bcs lot of people do custom kernel moduels for their hardware mods and it's a limiting factor atm
<KREYREN_oftc>
i am aware of the potential issues i want to just document what is needed and make a tiny kernel and then defconfig
<KREYREN_oftc>
so defconfig for everyone and tiny for those who want deep optimizations
<apritzel>
you don't need to compile the whole kernel if you just want to compile an off-tree module, you just need the source and "make prepare", I believe, then run the module Makefile
<apritzel>
"make modules_prepare" that is
<MoeIcenowy>
BTW I have a Olimex TERES-I too
<MoeIcenowy>
despite I initially did the ANX driver on Pinebook
machinehum has joined #linux-sunxi
<KREYREN_oftc>
apritzel, it's also a development thing when if there is an issue in the linux kernel to have less of a noise to siv through and be able to compile the kernel in a reasonable time in case ccache is not an option e.g. NixOS
<KREYREN_oftc>
MoeIcenowy, cool
<KREYREN_oftc>
hmm i just checked 2 u-boots one from nixos and the other from the pmos which i am developing atm and the nixos works and pmos doesn't despite them both having the same packaging instructions
<KREYREN_oftc>
well version is different maybe there is a regression in 2023.10
<apritzel>
KREYREN_oftc: please try mainline U-Boot (2024.01 is out), and report any issues. The display bridge chips support is in the defconfig, so this is supposed to work
<gamiee>
ohhh, amazing, all those are good to know, thanks :)
warpme has quit []
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
warpme has joined #linux-sunxi
mripard has joined #linux-sunxi
apritzel has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #linux-sunxi
vertex004 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
dsimic is now known as Guest14178
dsimic has joined #linux-sunxi
machinehum has joined #linux-sunxi
Guest14178 has quit [Ping timeout: 480 seconds]
apritzel has quit []
apritzel has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
vertex004 has quit [Remote host closed the connection]
<apritzel>
gamiee: so there you have it: the szemzoa's awboot repo contains Linux patches, including pinctrl, clock and stuff. So they just need to be send ...
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
Guest14117 has left #linux-sunxi [#linux-sunxi]
aperezdc has joined #linux-sunxi
tnovotny has joined #linux-sunxi
aperezdc has quit [Quit: aperezdc]
KREYREN_oftc has quit [Remote host closed the connection]
aperezdc has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
Jookia has quit [Read error: Connection reset by peer]
Jookia has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum2 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<gamiee>
yeah, I guess szemzoa doesn't have time for that, or?
<gamiee>
Also, sunxi-fel tool intentionally doesn't have write_sid functions?
<apritzel>
that sounds like asking for trouble and people bricking their chips
<gamiee>
yep, so intentionally. I use it for writing unique ID of the device into SID
<gamiee>
Anyway I have mechanism for writing it already from Linux userspace, so I guess I will keep use it, unless there will be interest to add this functionality to sunxi-fel tool, but well.. Maybe it can be there, but disabled by default by macro, so people which want and know how to use it, they will compile the tool with macro defined.
tnovotny has quit [Quit: Leaving]
<apritzel>
gamiee: yeah, feel free to push a PR to the github
<apritzel>
gamiee: and what kind of unique ID? for what, exactly? Can't you use the already existing SID ID, as exposed via the serial number in the DT? Or the generated MAC address, which is ideally unique as well?
<gamiee>
apritzel: Sweet! It might take some time, but I will definitely add this. About the what kind of unique ID. Yeah, I knew about SID ID or MAC Address, but this ID also contains information about the version of board, and I use it also as security measure, if someone will dump my firmware and put it into another H3.
machinehum2 has quit [Ping timeout: 480 seconds]
<gamiee>
hmm, go 0xffff0020 doesn't work anymore to get into FEL mode?
<gamiee>
oh wow, I was bit worried how painful would be to boot my "recovery app image" through FEL mode, and it ended up being working absolutely perfectly on first try, this is amazing, I love it.
<apritzel>
the direct branch into the BROM was always sketchy, the BROM codes makes certain assumptions about the state of the system
vpeter has joined #linux-sunxi
<gamiee>
I thought that this is the issue. Thankfully not important, I should rather do "force-fel" SD card :D
warpme has quit []
<apritzel>
yes, that is the safest, or a FEL button (but I guess you don't have one?)
<apritzel>
there is always interest in providing some "fel-reset" U-Boot command, happy to look at patches
<apritzel>
there were some in the past, but that didn't look right
<gamiee>
I do! Banana Pi put one on PCB.
<gamiee>
Doing such patch would probably need to check out BROM assembly and why it doesn't like the current state, but maybe a task for some free day :P
<apritzel>
there are some SoC specific tricks to safely trigger FEL mode, for instance through some clever core or system reset
<apritzel>
or for instance using the CPU hotplug facility
warpme has joined #linux-sunxi
<jernej>
apritzel: speaking of macs, on Tanix TX6, for some reason, U-Boot occasionally creates different mac address
<jernej>
so my dhcp assignes different ip
<jernej>
but this alternative mac is always the same
<apritzel>
jernej: oh, really? Never heard of this problem before
<jernej>
tbh, I never did much of investigation
<jernej>
oh, no
<jernej>
sorry, mac must be the same
<jernej>
because tftp boot always works
<apritzel>
the only thing I can imagine is if reading from the SID fails. That's definitely true for boxes using "secure boot", at least from non-secure state, as in U-Boot proper
warpme has quit []
warpme has joined #linux-sunxi
ftg has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
<jernej>
linkmauve: with ndufresne help, I can now inspect tiled NV12 output too (via gstreamer conversion). So can you provide 4:4:4 jpeg sample?
<jernej>
linkmauve: force 420 bit seems to be present from VE version 0x1639 (A80) onwards
<linkmauve>
Why is it only twice as high btw, and not also twice as wide?
<linkmauve>
Does that mean 4:2:2 would end up the same way?
<jernej>
I wouldn't know
<jernej>
can you provide raw sample?
<jernej>
linkmauve: this version of CedarX that I'm currently looking into, uses force bit only for 422. If HW doesn't support force bit, it does some software postprocessing.
<jernej>
so even if parser wouldn't fail, decoder would, later
<jernej>
due to missing quantization table and huffman tables
<linkmauve>
Doesn’t it use the default tables in case it is missing?
<linkmauve>
How do software decoders decode this JPEG fine?
<jernej>
maybe there are default tables after all
<jernej>
linkmauve: I found something interesting. On older SoCs, 4:2:2 and 4:4:4 subsamplings are decoded to special tiled 4:2:2 format
<jernej>
and later SW converted to tiled 4:2:0
apritzel has joined #linux-sunxi
<jernej>
linkmauve: you can try display it with DRM_FORMAT_NV16 and DRM_FORMAT_MOD_ALLWINNER_TILED modifier
<jernej>
but I suppose Cedrus overwrote some memory, since 422 needs larger buffer
evgeny_boger has joined #linux-sunxi
warpme has joined #linux-sunxi
<gamiee>
It is really... Newbie question, but please, could anyone explain me what exactly "CPUIdle" and CPUFreq (DVFS) drivers do, in relation of Sunxi SoC?
<linkmauve>
Hmm, WARNING: erroneous pipeline: could not set property "format" in element "rawvideoparse" to "nv16-32l32"
<linkmauve>
It seems Gstreamer isn’t wired for this format.
<linkmauve>
I’ll try DRM.
<apritzel>
gam
<apritzel>
gamiee: cpufreq is for CPU frequency setting (along with voltage)
<linkmauve>
Meh, it seems my HDMI cable is getting detected more and more as disconnected even though it is plugged in.
<apritzel>
gamiee: that's done in the kernel: the DT describes which clock drives the CPU(s), which regulator supplies the CPU(s), and how to check the temperature
<apritzel>
and the kernel cpufreq system ties this all together and lets a "governor" decide at which frequency the CPU cores should run
<apritzel>
it then tells the regulator to potentially adjust the voltage, and the clock driver to change the PLL frequency
<apritzel>
and the subsystem monitors the CPU temperature, and if it gets too hot, it clocks down the cores
<apritzel>
DVFS stands for "Dynamic voltage and frequency scaling" and is the generic term for this idea, cpufreq is the name of the Linux subsystem
<apritzel>
cpuidle on the other hands allows cores to *sleep*, so they don't execute any instructions
<gamiee>
apritzel: Thanks! So, as far as I understand, there is required driver for clock (so kernel can change frequency going into core), temperature sensor driver, and then a way to change voltage, thus drivers for PMIC, right? How stuff works when there is no driver for this? Fixed clock frequency and cpu voltage?
<gamiee>
but for cpuidle, there is need of separate "supervisor" in our case Crust, right? But if this is true, H616 cannot have cpuidle, or it can?
<apritzel>
well, with a fixed clock frequency, you simple cannot scale
<apritzel>
with a fixed voltage you might be able to, that depends on the implementation, but you won't save as much power, as this goes with the voltage squared
<apritzel>
there is "WFI" (wait for interrupt), which is an architectural instruction that pauses the core, and depending on the implementation, already saves some power
<jernej>
linkmauve: I meant DRM, sorry. gstreamer has only nv12-32l32 implemented
<apritzel>
gamiee: the downside is that wfi cannot sleep very deep, as it's supposed to wake up very quickly once an interrupt arrives
<apritzel>
so firmware or a mgmt core can put the CPU in a deeper sleep state, which is implementation specific
<apritzel>
I don't think you necessarily need a management processor for some deeper sleep states, you could implement this in EL3 (TF-A)
<apritzel>
you probably need some extra core for decent suspend/resume, at least if you want to save more power, because you can then power down the whole CPU cluster
montjoie has joined #linux-sunxi
<apritzel>
my experience with cpuidle is patchy at best, so take that part with a grain of salt
<gamiee>
This leads me to another question, where is EL3 running? E.g. when u-boot is running on core0, the EL3 is ran on core1, and then stays there? Or how it is "multi-threaded" between OS?
montjoie_ has quit [Ping timeout: 480 seconds]
<gamiee>
And thanks, this level of explanation was exactly what I was looking for. I thought it might work like this, just wasn't sure. But I am actually surprised that WFI instruction is also used on "non-realtime OSes"
<apritzel>
no, EL3 is an exception level of a core. Initially the core starts up in EL3
<gamiee>
so it is SPL -> EL3 -> u-boot proper? Or EL3 is even before SPL ?
<apritzel>
SPL runs in EL3, hand off to TF-A (still in EL3), which then drops to EL2 and into U-Boot proper
<apritzel>
EL3 is always secure
<apritzel>
TF-A code stays in SRAM, and gets invoked on a SMC call again, for instance when the kernel issues a PSCI call
<apritzel>
same thing like userland and a kernel, just two levels higher
<gamiee>
but "Execution Level" is "only" state of processor / registers, isn't it?
<apritzel>
yes
<gamiee>
Sorry, I really don't know much about those execution layers. Does this mean that "TF-A" is not running simultaneously with OS, but rather, is once loaded into SRAM, and if kernel needs something, through SMC call, it will elevate into EL3 and jump into TF-A code in SRAM?
<apritzel>
yes
<apritzel>
and it's actually called "exception level"
<apritzel>
as I said: it helps to think of this like userland/kernel(EL0/EL1) or guest/hypervisor(EL1/EL2)
<gamiee>
oh wow, that's really cool. I always had assumption that TF-A somehow runs simultaneously with kernel, but it did not gave me a sense how that would be "threaded" :D
<gamiee>
ahh, exception level, thanks. I confused it with something else. And yeah, it now all makes sense.
<apritzel>
since TF-A runs in secure state, it could be triggered by secure interrupt, asynchronously of the kernel
<apritzel>
or by an exception, that is either synchronous (the kernel tried to access a secure memory location or tried to use a feature that is secure-only)
<apritzel>
or it could be an asynchronous exception, if that is configured to be taken to secure state
<apritzel>
so TF-A *could* be triggered independently of the kernel, but we don't use that in sunxi
<apritzel>
and in any case each core runs only in one exception level at a time, so there is indeed no threading or such
<gamiee>
What do you mean by that it can be triggered independently of the kernel (thus async)? I understand that it can be triggered in sync way by doing SMC call, but what is the "async" scenario?
<apritzel>
asynchronous basically means external triggers, not CPU instructions: so mostly interrupts, or hardware error like bus errors or a device signalling a fatal condition
<gamiee>
makes sense, I had this assumption, but wasn't sure.
<gamiee>
This reminds me when I was doing research about how kernel communicates with Crust on H3.
<gamiee>
Since H3 doesn't need/have TF-A, the PCSI calls are handled by u-boot.
<gamiee>
So I guess the principle is same, that u-boot is living in SRAM, and then invoked by kernel by some command (I don't exactly remember if it was SMC or another call)
<apritzel>
yes, for ARMv7 we have some *parts* of U-Boot that stay behind in SRAM and handle PSCI calls
swiftgeek has quit [Quit: swiftgeek]
<apritzel>
that's all separately linked and relocated into SRAM early on, when U-Boot initialises
swiftgeek has joined #linux-sunxi
<apritzel>
we could actually do both in both architectures (run TF-A on an H3, or run U-Boot's PSCI code on an A64), but that's not implemented
<gamiee>
cool, very cool design. I am actually happy that i don't need TF-A on H3 :D
<gamiee>
Although, I might try to implement crust into buildroot, although, I don't know how I should deal with another arch compiler. Need to ask buildroot devs someday
<apritzel>
the downside is that U-Boot's PSCI implementation is somewhat basic, at least the sunxi version, whereas TF-A serves as the reference implementation of PSCI, with all the latest features
<gamiee>
well, at least for me, it have all stuff I need :D btw.
machinehum has joined #linux-sunxi
<apritzel>
it should be pretty straightforward to pimp U-Boot's PSCI to proper v0.2 or v1.0
<gamiee>
I want to make some stuff in Crust configurable. For example, to enable/disable HDMI CEC or IR wakeup, without need of re-compiling the Crust. From what I remember, kernel is telling through "PCSI" about which wake up sources to use, so implementing that would be the best, I am right?
<apritzel>
that's something for smaeul to answer, but IIUC crust doesn't really care, as it relies on Linux to leave that device running, and crust just reacts to any interrupt that's triggered by the wakeup source device
<linkmauve>
jernej, I get EINVAL when doing the ADDFB2, still debugging why.
<gamiee>
Hmm, then I can somehow instruct Linux to turn off HDMI-CEC and/or IR, so it doesn't generate interrupt for wake up?
<linkmauve>
Possibly because the kernel knows there isn’t enough memory for this format, so it rejects the reinterpretation of the buffer.
<jernej>
yeah, most likely
<linkmauve>
Does that mean we should add NV16 support proper?
<jernej>
no, just convince cedrus to give enough memory
<jernej>
quick hack should be ok
<jernej>
(for testing purposes)
<linkmauve>
I’m thinking about the end result, that should support NV16 (ST16? ^^') and only be allowed when the input is 4:4:4 or 4:2:2?
<linkmauve>
But the driver can’t know which format to expose to ENUM_FMTS before it has parsed the JPEG…
<jernej>
first you need to confirm that this is really the case
<linkmauve>
(ITYM in the _32L32 version.)
<linkmauve>
Building a kernel to test that theory.
<jernej>
and second, welcome to the Cedrus convoluted world of setting output format
<jernej>
:)
<linkmauve>
Haha. :D
<linkmauve>
Woohoo, it displays just fine! \o/
<linkmauve>
That makes sense, given how the output looked before.
<jernej>
hm... request api has advantage here. One of the first steps is to set controls, which then determine available output formats which in turn makes sure buffers have proper size.
<linkmauve>
So we’d add request support to the JPEG uAPI?
<jernej>
it would solve some problems, but better discuss that at #linux-media
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
<gamiee>
apritzel : going to sleep now, thank you for your time and answers, it explained me many questions which were puzzling my mind for quite some time :D
<linkmauve>
Moved the discussion there.
<paulk>
jernej: btw the reference code only seems to support few variants of jpeg
<paulk>
so you first have to set the coded format, then submit controls and then list picture formats
machinehum has quit [Ping timeout: 480 seconds]
<paulk>
the current cedrus design doesn't support that so well IIRC
<linkmauve>
Oh!
<paulk>
but I think I improved this side a bit in my encode rewrite
<jernej>
linkmauve, paulk: yeah, tiled NV16 support was just figured out today
<linkmauve>
So what I’ve been doing with VP8, of only setting the ext_ctrls right before QBUF is wrong… Well, at least VP8 only supports 4:2:0 8-bit so it’s unlikely to ever change.
<jernej>
and it seems to apply only to JPEGs
<paulk>
jernej: very nice work!
<paulk>
linkmauve: indeed currently it doesn't matter so much
<paulk>
and the driver is very lax (too much) about it
<paulk>
cedrus is currently very lax about a lot of things haha
<jernej>
tbh, I would rather see that there is no such thing. It complicates kernel driver :)
<paulk>
hehe it's v4l2
<linkmauve>
Are there other drivers which are stricter about the order of things?
<paulk>
driver holds quite a lot of state
<paulk>
especially for codecs
<paulk>
linkmauve: hantro is slightly better
<paulk>
but it's still quite a ad-hoc architecture
<linkmauve>
I’ve been testing hantro lately and it fails to decode any VP8 I throw at it without outputting a single error, I don’t consider that strict. :p
<paulk>
both hantro and rkvdec were initially architectured more or less like cedrus
<paulk>
linkmauve: haha
<linkmauve>
It gives me a mostly-green image as an output, probably reading from uninitialised memory.
<linkmauve>
as a capture*
<paulk>
anyways that was a big motivation to make a complete architecture rewrite
<paulk>
ouch
<paulk>
maybe try with the gstreamer implementation
<paulk>
I had vp8 working with it not very long ago
<paulk>
jernej: linkmauve: can you output untiled too?
machinehum has joined #linux-sunxi
<paulk>
or is it mandatory to use tiling for jpeg?
<jernej>
no, it's a bit convoluted
<jernej>
from A33, it supports also untiled, like any other
<jernej>
but from A80 onwards, it supports forcing 420 mode for 422 and 444 sources
<paulk>
ah so it adds a chroma sub-sampler
<linkmauve>
paulk, VP8 decoding on A64, A10 and A20 works perfectly already with onix. :)
<paulk>
linkmauve: ah right you meant hantro
<paulk>
sorry
<paulk>
I mixed things up
<jernej>
so, for socs older than A33, and 422 and 444 sources, you'll get tiled NV16, no questions asked
<linkmauve>
Yeah, interestingly I have the exact same artifacts on rk3568 and rk3399, haven’t tested on rk3588 yet since it isn’t wired up.
<linkmauve>
AV1 is the only supported codec so far on that SoC. :D
<paulk>
lol how ironic
<jernej>
hm, maybe there is linear NV16 support for JPEG on A33 and newer. Need to test that.
<linkmauve>
paulk, heh, that’s the only reason I got offered that board, so that I could add AVIF support in addition to JPEG and WebP. :D
machinehum has quit [Ping timeout: 480 seconds]
<paulk>
linkmauve: awesome project!
<paulk>
and really nice hardware too
<paulk>
I mean this level of performance and multimedia features for a board that can run with fully free software
<paulk>
I would never have imagined this 10 years ago
<paulk>
back when I was fighting against the exynos4 trying to at least get the camera working without blobs
<paulk>
no gpu support, no video codec support
<paulk>
it was hell
<linkmauve>
Speaking of which, I think I’ll release onix 0.2.0 quite soon with JPEG support for both encoding and decoding, in addition to WebP decoding.
<linkmauve>
If we ever decide to add a request API for JPEG decoding that’ll also go in. :)
<linkmauve>
paulk, ah, rk3588 doesn’t have the GPU working yet in mainline, only with the new panthor driver, including some not-yet-merged Mesa branch.
<paulk>
ah I see
<paulk>
and it's the one that relies on a firmware right?
<paulk>
linkmauve: normally JPEG doesn't need to be stateful
<linkmauve>
Yeah.
machinehum has joined #linux-sunxi
<paulk>
stateless*
<paulk>
because jpeg state is self-contained
<linkmauve>
paulk, read the discussion at #linux-media. :)
<paulk>
ah!
<linkmauve>
This is about knowing which formats we can output at S_FMT time.