<apritzel>
karlp: this .bin file is the SPL and a FIT image glued together
<apritzel>
karlp: the SPL is having an Allwinner eGON header, so the BootROM recognises it and loads and executes it
<apritzel>
the SPL then looks at the rest of the file, and detects a FIT image in this case
<apritzel>
then parses this, loading the remaining firmware components: Trusted Firmware, the crust firmware (for the ARISC mgmt processor), and U-Boot proper, plus the DTB
<apritzel>
this is done in U-Boot's common/spl/spl_fit.c:spl_load_simple_fit() function
<apritzel>
this above is the MMC or SPI flash booting sequence, loading via FEL is a bit different:
<apritzel>
sunxi-fel loads the SPL and executes it (to initialise DRAM, so that we can load the other components)
<apritzel>
the SPL then returns to FEL, so it's back to sunxi-fel to do the rest of the loading
<apritzel>
so we copy the functionality of spl_load_simple_fit() in sunxi-fel now, load all the integrated binaries, then execute the next in line, in this case TF-A
sunshavi has joined #linux-sunxi
lurchi_ is now known as lurchi__
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #linux-sunxi
<libv>
retorical question: if drivers spend only 3.0 and 3.3% respectively of loc on register accesses, what does that say about the driver infrastructure?
Mangy_Dog has quit [Ping timeout: 246 seconds]
apritzel has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
lerc has quit [Remote host closed the connection]
lerc has joined #linux-sunxi
popolon has quit [Quit: WeeChat 3.0]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
<tuxd3v>
hello
<tuxd3v>
I have orange pi one plus..
_whitelogger has joined #linux-sunxi
<tuxd3v>
I build recently a 5.10.2 kernel for it with sun8i-ce/sun8i-ss, and retired the sun4i-ss
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
damex has quit [Ping timeout: 256 seconds]
iamfrankenstein has quit [Ping timeout: 256 seconds]
cmeerw has joined #linux-sunxi
apritzel has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<apritzel>
tuxd3v: what is the actual problem? I mean I don't see big problems in your log? Or does it stop booting afterwards?
gediz0x539 has quit [Quit: Leaving]
gediz0x539 has joined #linux-sunxi
<gediz0x539>
it it necessary add a "sun5i-a13-mali" compatible to yaml file while submitting a patch? it looks/performs identical with "sun4i-a10-mali". i even made it work using "sun4i-a10-mali".
<wens>
it would be better to add it to the driver, since the compatible is already listed in the binding
<gediz0x539>
wens: okay. thanks.
<wens>
oh sorry, I thought it was about the frontend
<gediz0x539>
nope, gpu
<wens>
for mali, yes, you need to add the new compatible (even if it has a fallback) to the bindings
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #linux-sunxi
apritzel has joined #linux-sunxi
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #linux-sunxi
<willmore>
libv, depends on what the rest is spent on. If it's conditionals (if/switch) trying to figure out what obscure register to fiddle with, then the driver probably supports too many devices. If it's data movement/formatting, then it's providing a non-native API and user space should take up more of the burden. If it's doing computation, then someone done messed up but good.
<libv>
willmore: i started writing display drivers in 2003 :)
<willmore>
It's okay to be new, no one will hold that against you.
<libv>
i am almost there on writing planar rgb24 to nv12 conversion on the a20 mixer processor
<libv>
in v4l2
<willmore>
In the driver?
<libv>
which has a higher register access to loc rate than the csi1 driver i wrote because the existing csi0 was not doing anything on the bpi and camera module with the code available last year
<libv>
i think i might have hit 4% now that i added the nv12 output code that i am debugging right now
<willmore>
The csi module generates the data in nv12? (or rather the camera attached to it)
<libv>
no
<libv>
h.264 encoding needs nv12
<libv>
the fosdem video test hw create 24bit rgb, but in separate planes
<libv>
which both the display engine handles just fine
<willmore>
Ahh, you've got a camera that generates rgb24 (split planes) and you need nv12 to feed to the H.264 encoder?
<libv>
yes, so i rope in the mixer processor (whose driver used to be called g2d)
<libv>
and it was astounding how much time i once again spent on working around v4l2 awkwardness
<willmore>
It's not really a camera but an HDMI/CSI brdige, right? Or am I remembering a different project of yours?
<libv>
it currently is a tfp401, so dvi to parallel rgb
<willmore>
Okay, DVI bridge.
<libv>
which is taken in fine by our csi1 engine
<libv>
and we will use adv7611 for the next version of the board
<libv>
we just used the existing adafruit tfp401 hdmi to parallel lcd module for our test hw
<willmore>
What difference will that make? Does it offer different output formats or something?
<libv>
the csi1 driver has just below 3% register accesses, it is also very trivial hw, yet the driver is 1.4kloc thanks to v4l2
<libv>
willmore: with the current fosdem video setup, audio is concentrated at the professional camera, which then passes it on through hdmi
<libv>
so we need to be able to take in audio over i2s
<willmore>
Is that a lot of templates or something or just converting native data structures to the v4l2 structures?
<libv>
and the original difference between dvi and hdmi is that the blanking area was now used to pass things like audio
<libv>
willmore: v4l2 exists to support TV capture cards
<libv>
analog tv
<willmore>
And the tfp401 doesn't handle the audio as it's DVI not HDMI... Gotcha.
<libv>
everything else was thrown in afterwards and somewhat made to fit
<libv>
and it is not very fit for purpose any more
<willmore>
Well, yes, originally it was. Isn't it flexable enough to handle pretty much any capture source?
<libv>
not cleanly
<libv>
not sanely
<willmore>
So you need a v4l3?
<libv>
or just waste a lot of time and complain and get it done anyway
<libv>
willmore: we now have dmabuf
<willmore>
Which lets a kernel driver export a peripherial DMA accessable chunk of memory to user space?
<libv>
creating infrastructure that supports devices that handle n buffers to n buffers conversion should not be that insane
lurchi__ is now known as lurchi_
<libv>
and will get the time spent on actually poking the hw way up
<linkmauve>
I have an A20 board which consistently shutdowns after running kmscube for a few seconds. It spins the cube from less than 1s to a record of 148s before going down.
<libv>
willmore: and to other infrastructure, like framebuffers for kms
<linkmauve>
What could I use to debug that?
<libv>
linkmauve: power?
<linkmauve>
I’m running Lima from Mesa 20.3.1 on it.
<willmore>
linkmauve, you might want to start with simpler tests. You may have a power supply or thermal issue.
<willmore>
linkmauve, try cpuburn on it to see if it's a power issue.
<linkmauve>
The power comes from a standard power socket saying 5V/2.1A.
<libv>
willmore: things like the tfp401 and adv7611 do not need to deal with buffers in any way
<willmore>
If cpuburn survives, then your power and cooling (and CPU clocking) are probably good.
<willmore>
libv, understood, that's what the csi does.
<linkmauve>
Thanks, I’ll test cpuburn.
<willmore>
linkmauve, but throught a micro-USB connector, right?
<libv>
they are "decoders", and they need to be configured and have start/stop/reset and interrupts
<linkmauve>
Mini*-USB, but yes.
<libv>
then there are capture engines, which create dma buffers
<linkmauve>
I have no cooling for anything, but I’ve been running my other boards the same way for years.
<willmore>
linkmauve, that's not a great power connector and can cause voltage drop under current load which can cause brownouts/resets.
<linkmauve>
:/
<libv>
then there are converters, which take N buffers and turn them into n buffers (from 2d compositing to colourspace to rotation to scaling, to encoding/decoding of compressed video)
<willmore>
libv, right, the tfp401/adv7611 take a digital stream in, decode it, and stream it back out in a modified format. The CSI module takes that and puts it into a buffer.
<libv>
they do not need to be forcibly thrown into infrastructure that likes to spend its time getting teletext info from the blanking of analog TV signals
<linkmauve>
willmore, hmm, should I target burnCortexA8 or burnCortexA9, on this Cortex-A7? ^^'
<willmore>
libv, gotcha.
<libv>
the different bits need to agree on a common format, and then pass buffer handles back and forth, together with some signalling
<linkmauve>
Both seem to work, although using only one core.
<willmore>
linkmauve, there's a secret decoder keyring for that somewhere. I don't remember immediately which one to use. Probably A8.
<willmore>
linkmauve, you'll want to make sure that both cores (A10 is dual core, no? I don't go back that far with Allwinner) are running cpuburn to get fullest loading.
<willmore>
Let them run for a few minutes.
<linkmauve>
It’s an A20 which is dual-core yes.
<willmore>
In addition to power and heat, the cmscube also stresses the memory interface. If your memory is running at too high of a clock, you can experience graphical glitches or lockups.
<linkmauve>
After three minutes the board is slightly warmer, load average is 2, but no unexpected shutdown. The cursor in the TTY is blinking irregularly though.
<linkmauve>
/sys/devices/platform/soc/1c25000.rtp/sun5i-a13-gpadc-iio.0/iio:device1/in_temp_raw gives higher values than when I was running kmscube, no idea which units it reports in though.
<willmore>
libv probably has some input on this, but I don't think kmscube usus more power than two cores running cpuburn, so you're probably good for power/thermal if you pass the cpuburn test--leaving only memory.
<linkmauve>
Currently at 1994, while it was around 1920 with kmscube running just before shutting down.
<willmore>
That's probably a CPU scheduling issue. UI code is notoriously bad for cpu scheduling.
<willmore>
sounds like you've ruled out power and heat.
<willmore>
IIRC, the memory clock is settable in the DTS, you might want to see the A20 page on the wiki and see what the next step down is and try that.
<linkmauve>
Temperature reached 2004 after seven minutes, and now the board feels warm.
<linkmauve>
I’ll stop that test. :)
<linkmauve>
What is instruction 0xf903fb04? It isn’t supported by perf’s disassembler.
<linkmauve>
Ok, I also tested mpv with its GPU renderer and it crashed the board in under two seconds.
lurchi_ is now known as lurchi__
<linkmauve>
I tested the same microSD in another (identical) board first, and it’s been rendering kmscube for a good five minutes.
<linkmauve>
Oh, but when I ran burnCortexA8 alongside it crashed right away.
<willmore>
Hmm, that's not good. :)
<linkmauve>
I would expect so. :p
<linkmauve>
When I attached perf to a running kmscube I got a black screen for a fraction of second, but it continued running after that.
<willmore>
Where without perf it crashed?
<linkmauve>
Oh I got another failure mode, running kmscube and cpuburn alongside, now the screen is stuck in kmscube-gray.
<linkmauve>
willmore, yes, it crashed without perf involved.
<willmore>
Both boards crash? One crashes with just kmscube and the other requires cpuburn to run alongside kmscube?
<linkmauve>
Yes.
<linkmauve>
Both of those boards are Olimex Lime2, that might be relevant.
<linkmauve>
I also have two Lime1 with A20 and one Lime1 with A10, if you think this is worth comparing.
<linkmauve>
The second board (which requires cpuburn+kmscube to crash) is currently running cpuburn alone, and seems to sustain it just fine.
<linkmauve>
After five minutes of cpuburn it seems to do fine.
<linkmauve>
Ok, I found another way to crash the second board much more quickly, by using a shadertoy shader.
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 240 seconds]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
<tuxd3v>
montjoie, many thanks, probably it could be some tests option that get enabled, next time I will to a menuconfig, I will check that too
<tuxd3v>
My board seems to be working like before, I don't notice nothing strange, apart of taking more time to boot..
<tuxd3v>
gediz0x539, thanks, I don't have all the logs I got some time without the chat, as I was testing a new distro in another partition, on my builder machine
<tuxd3v>
but its good to know
<tuxd3v>
In any case, I have the 4 cpus online, and I am able to launch 4 threads on then
apritzel has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
<smaeul>
apritzel: USB PHY is documented in the T7 manual, so enable_pmu_unk1 can be replaced by its real meaning if you want
<smaeul>
section 10.6.6
<smaeul>
s/T7/A50/ ... too many manuals open at once
<apritzel>
smaeul: ah, thanks for the pointer! MoeIcenowy mentioned that bit name already, but this is even better
s_frit has quit [Remote host closed the connection]