damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
yann has quit [Ping timeout: 265 seconds]
apritzel has left #linux-sunxi ["Leaving"]
apritzel has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
lucascastro has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
lucascastro has joined #linux-sunxi
lucascastro has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
ldevulder_ has quit [Read error: Connection reset by peer]
ldevulder_ has joined #linux-sunxi
<bauen1>
smaeul: does 49d98cd549c3e2cb5fa4316e1ed365af4d95d9ba in trusted-firmware-a mean that you've figured out what kind of SPC the H6 has and which peripheral corresponds to which or just what each register does ?
victhor has quit [Remote host closed the connection]
lurchi__ is now known as lurchi_
apritzel has joined #linux-sunxi
<bauen1>
so taking another look at what the rtc actually offers, it looks like i can sacrifice the alarm0 and the "crypto" part and have a total of 84 bytes (minus 1 bit) that are preserved, take ~52 bytes to make the sbrom actually secure and i have just about 32 bytes for a decryption key and a replay counter
<bauen1>
and it limits the BL2 / spl size to a hard 32kb (minus a few hunders bytes for toc0), and the default u-boot spl takes up most of that leaving just about 472bytes, but doesn't actually have the ability to do signature checking
gameblabla has joined #linux-sunxi
<gameblabla>
Hello! Back with another issue. How would i force 640x480 32bpp via uboot ? I tried setenv video-mode sunxi:640x480-32@60,monitor=hdmi,hpd=0,edid=0 in boot.cmd but no luck. The only output i was able to get was video=HDMI-A-1:d disp.screen0_output_mode=720x480p60 but even that forces the display to 720p, which i don't want in my case.
apritzel has quit [Ping timeout: 256 seconds]
lucascastro has quit [Ping timeout: 256 seconds]
<bauen1>
oh nevermind again, spl does support signed images, it's just hidden and it's massive (seems to add ~36kb :D)
<jernej>
gameblabla: for which SoC and you mean for Linux?
<gameblabla>
A20 and yeah linux
<jernej>
disp.screen0_output_mode is for BSP kernel
<jernej>
anyway, with mainline kernel you can only force video resolution via kernel arguments
<jernej>
so, you should set bootarg accordingly
<gameblabla>
Yeah i'm using the mainline kernel. Guess that explains why it didn't work
<karlp>
unlesssome other uboot thing uses "video-mode" to construct boot args...
<karlp>
people script uboot far beyond sanity IMO
asdf28 has quit [Ping timeout: 260 seconds]
<gameblabla>
Hmm so i tried video-mode=sunxi:640x480-32@60d,monitor=hdmi,hpd=500,edid=0 in bootargs but it seems to try to display 720p (?) display on the RGB LCD. If the RGB LCD is disabled later after it booted, it still defaults to 720p
<gameblabla>
Even though i had video=Unknown-1:640x480-32@60 set
<jernej>
gameblabla: my knowledge of A20 and RGB interface is weak, but I think there is no mainline driver for it
<gameblabla>
Well it certainly works for me
<jernej>
in this case it's probably used through simplefb, which is set up by U-Boot and used as-is in Linux
<jernej>
wait, RGB is LCD?
<gameblabla>
yes
<jernej>
I mixed up with VGA
<gameblabla>
yeah it's not vga
<libv>
jernej: there is no working vga in mainline on a20
apritzel has joined #linux-sunxi
<jernej>
exactly, but simplefb should work
<libv>
i am running an rgb lcd on both the fosdem test hw and a bpi on 5.9
<libv>
and hdmi
<gameblabla>
Alright so video=Unknown-1:640x480-32@60 video=HDMI-A-1:d video-mode=sunxi:640x480-32@60,monitor=hdmi,hpd=500,edid=0 makes the RGB LCD not misbehave (it displays 640x480) but HDMI still outputs 720p xox
<libv>
gameblabla: what issue are you actually trying to solve, what is your endgoal?
<gameblabla>
I want to output 640x480p over HDMI, not 720p
<libv>
why?
<libv>
(as that does not smell like it is the real goal of what you are trying to achieve)
<gameblabla>
Why not ? Besides i'm using SDL 1.2 with the kmsdrm backend from OpenDingux and software rendering is slow at 720p with Gmenu2x
<gameblabla>
And i like when things are consistent
<libv>
where does the rgb lcd come in in all this?
<gameblabla>
Well it needs to work still :>... Basically i have a small buildroot distro that boots to RGB LCD at boot but later the user can switch between LCD or HDMI through a small app
<gameblabla>
It basically just does echo off > /sys/class/drm/card1-Unknown-1/status;echo on > /sys/class/drm/card1-HDMI-A-1/status and vice-versa
<gameblabla>
So i need both to work ok
<libv>
the user being... you?
<gameblabla>
And a few other people as well :>
<apritzel>
bauen1: where does this "hard 32KB" limit come from?
<libv>
gameblabla: what hw is this?
<gameblabla>
It's the Retrostone 2 to be precise. It has an Allwinner A20 with an LCD and an HDMI port
<gameblabla>
But yeah so far it's working, except for HDMI that outputs 720p instead of 480p
<libv>
gameblabla: why not use the full resolution of the lcd, and use the display engines scaler?
<libv>
err, lcd being hdmi connected device
<gameblabla>
it is a 640x480 screen
<libv>
that only costs memory bandwidth
<libv>
and you can display in parallel
<libv>
and upscaling 640x480 is not that memory intensive
<gameblabla>
is that possible on the A20 ? Because i noticed that SDL 1.2 KMSDRM was much slower over HDMI 720p, even when upscaling with the Display Engine from a lower resolution like 320x240
<libv>
not like the downscaling from 1280x720 to 320x240 that i was doing for the fosdem video hw in february
<libv>
what did you witness though, actual usage of the display engine, or sw/mali based scaling?
<gameblabla>
Most likely the display engine : i'm forcing 320x240 32bpp and i'm not using software scaling and much less the Mali
<gameblabla>
The display engine works fine for the LCD
<gameblabla>
While it does work fine over HDMI as well, it stretches 320x240 to the full 720p (resulting in a messed up aspect ratio) and seems slower.
<libv>
how can you tell?
<gameblabla>
It's not as responsive as it should be
<gameblabla>
But i'm gonna try with a benchmark
<libv>
then something is wrong
<libv>
if the application, or whatever SDL is doing does the overlay dance correctly, you should have less than one frame difference between both displays
<libv>
simply because they are not going to be in sync
<gameblabla>
i'm only displaying one at a time
<libv>
should not cost you any more in memory bandwidth, when done correctly
<gameblabla>
Oh nevermind, you're right
<gameblabla>
I misconfigured my capture card
<gameblabla>
although the aspect ratio is wrong, unless there's a way of telling the kernel/display engine to keep the aspect ratio ?
<libv>
of course there is
<gameblabla>
how ?
<libv>
kms?
<gameblabla>
that's not very specific :>
<libv>
have the application that listens to the hotkey or menu or whatever, do the kms dance properly
fl__0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 260 seconds]
<libv>
check out the fosdem video hw video, i am capturing planar RGB, captured from the speakers laptop (mine in this case, but it did that the whole weekend), with a hacked edid fake device, displaying the planar rgb buffer on hdmi at the native resolution of the projector, at the correct aspect ratio, and then also displaying it on the 320x240 lcd at the same time
<libv>
i now have working planar rgb to nv12
<gameblabla>
Ah, i see that you also used the A20 so i'm going to take a look
<apritzel>
bauen1: smaeul: do those CPU hotplug registers (magic + start addr) survive a watchdog reset? Or only a core reset?