<smaeul>
MoeIcenowy: I don't think SRAM A1 is available from the ARISC core at all on H5. BROM is mapped from 0x40000-0x4ffff (which is 0-0xffff on the ARM side, i.e. where A1 used to be), and 0x50000-0x53fff is the same from both processors (so part of SRAM A2 is duplicated at 0x10000-0x13fff from the ARISC side)
<smaeul>
DRAM repeats all the way up to 0xffffffff so it can't be mapped up there where the BROM used to be
cnxsoft has joined #linux-sunxi
<MoeIcenowy>
smaeul: possible
<smaeul>
I wrote a program to scan the entire address space for the header from u-boot SPL left in SRAM A1 and did not find it
<MoeIcenowy>
oh maybe they think SRAM A1 should only belong to ARM ;-)
<smaeul>
or they forgot to change the remapping when they moved it :)
<MoeIcenowy>
possible ;-)
<MoeIcenowy>
but for A64 it may be available?
<smaeul>
why does arisc need to read BROM? it's not even the right instruction set :P
<smaeul>
MoeIcenowy: address layout looks the same on A64
<L29Ah>
is there an adc on A20 that is usable from the mainline linux userspace?
<L29Ah>
touchscreen one seems to be used for touchscreen input exclusively
cnxsoft has quit [Read error: Connection reset by peer]
<wens>
you have to switch to the sun4i-gpadc-iio driver
<wens>
not the touchscreen one
anarsoul has joined #linux-sunxi
[7] has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
a|3x has quit [Ping timeout: 248 seconds]
iamfrankenstein has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
Ultrasauce has quit [Ping timeout: 248 seconds]
Ultrasauce has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
baali has joined #linux-sunxi
fkluknav has quit [Ping timeout: 258 seconds]
awais has joined #linux-sunxi
baali1 has joined #linux-sunxi
baali has quit [Ping timeout: 240 seconds]
fkluknav has joined #linux-sunxi
awais has quit [Ping timeout: 255 seconds]
awais has joined #linux-sunxi
Andy-D has joined #linux-sunxi
anarsoul|2 has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
Andy-D has quit [Quit: Alive/Dead]
HeavyMetal has quit [Ping timeout: 246 seconds]
fkluknav has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
baali1 is now known as baali
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
Mr__Anderson has quit [Quit: Leaving.]
jstein has joined #linux-sunxi
MoeIcenowy has quit [Ping timeout: 260 seconds]
MoeIcenowy has joined #linux-sunxi
fkluknav has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
baali1 has joined #linux-sunxi
baali has quit [Ping timeout: 258 seconds]
msimpson has joined #linux-sunxi
yann has quit [Ping timeout: 248 seconds]
chomwitt has joined #linux-sunxi
paulk-gagarine-s has quit [Quit: Leaving]
paulk-gagarine has joined #linux-sunxi
leviathanch has joined #linux-sunxi
jkarlson has joined #linux-sunxi
jkarlson has quit [Changing host]
jkarlson has joined #linux-sunxi
jkarlson has quit [Client Quit]
nemunaire has quit [Quit: quit]
chomwitt has quit [Ping timeout: 255 seconds]
Putti has quit [Remote host closed the connection]
yann has joined #linux-sunxi
chomwitt has joined #linux-sunxi
LargePrime has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
afaerber has quit [Ping timeout: 246 seconds]
LargePrime has joined #linux-sunxi
afaerber has joined #linux-sunxi
<shadeslayer>
MoeIcenowy: is there a way to make it work re vdpau?
sr-digitronic has joined #linux-sunxi
<shadeslayer>
I mean, it feels like it's that single ioctl that's going wrong, because once I remove the error handling around it, mpv starts the video, even if it doesn't render anything
lemonzest has joined #linux-sunxi
sr-digitronic has quit [Remote host closed the connection]
nemunaire has joined #linux-sunxi
sr-digitronic has joined #linux-sunxi
sr-digitronic has quit [Remote host closed the connection]
sr-digitronic has joined #linux-sunxi
Putti has quit [Ping timeout: 248 seconds]
fkluknav has quit [Ping timeout: 260 seconds]
Putti has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 258 seconds]
enrico__ has joined #linux-sunxi
Turl has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
baali1 has quit [Ping timeout: 246 seconds]
Turl has joined #linux-sunxi
Ntemis has joined #linux-sunxi
Turl has quit [Remote host closed the connection]
paintenzero has joined #linux-sunxi
baali has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
kaspter has quit [Client Quit]
Turl has joined #linux-sunxi
gumblex_ has joined #linux-sunxi
gumblex has quit [Ping timeout: 240 seconds]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
chomwitt has quit [Ping timeout: 246 seconds]
<wens>
a20 hdmi working :)
<wens>
I picked and cleaned up patches from Net147's sun7i-drm-wip branch
<Net147>
wens: thanks! =)
<KotCzarny>
nice
tlwoerner has quit [Ping timeout: 260 seconds]
mhlavink has joined #linux-sunxi
<willmore>
Yay!
awais_ has joined #linux-sunxi
awais has quit [Ping timeout: 264 seconds]
fkluknav has joined #linux-sunxi
jbrown has joined #linux-sunxi
kaspter has joined #linux-sunxi
baali has quit [Ping timeout: 248 seconds]
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
vagrantc has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
<buZz>
anyone have a idea on the batterylife of one of those TERES laptops?
<willmore>
buZz, likely yes.
<willmore>
Not me, but it's likely that someone does.
<buZz>
:)
<buZz>
i couldnt be more pedantic myself
<buZz>
but i'm still curious to how long you could run it ;)
* willmore
doesn't have one.
<buZz>
thats ok, i wont hold it against you
<willmore>
Any H6 boards rumored from the normal suspects? I saw a STB using one on cnxsoft.
<willmore>
:P
<willmore>
If I had one, I would hold it against me.
<oliv3r>
buZz: it is, but we are in the process of opening the repositories
<oliv3r>
it'll be lgpl licensed afaik
<oliv3r>
but since it's python code, you can look at it on any ultimaker 3 :p
<wens>
a20-drm-hdmi branch pushed to my github
<buZz>
oliv3r: noone i know has that ;)
<buZz>
i'll keep an eye on the github
<oliv3r>
wens: ok pulling
<oliv3r>
is it based uppon for-next?
kaspter has quit [Quit: kaspter]
<wens>
sunxi-next
<oliv3r>
then i may just cp your patches :)
<oliv3r>
8 patches? right?
<wens>
yup
Gerwin_J has quit [Ping timeout: 258 seconds]
<oliv3r>
excellent
enrico__ has quit [Ping timeout: 246 seconds]
enrico__ has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
awais_ has quit [Ping timeout: 248 seconds]
<oliv3r>
ah bah, the for-next misses your sun6i hdmi support stuff
<oliv3r>
tomorrow will be a new day for that :)
<wens>
which is why I base it on sunxi-next, which does have drm-misc-next folded in
<wens>
pushed an updated version (whitespace cleanups and commit messages)
<oliv3r>
okay :)
<oliv3r>
i'll see what works cleanest for me tomorrow
<oliv3r>
even so, thanks wens :)
<oliv3r>
hometime :)
leviathanch has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lemonzest has quit [Quit: Quitting]
baali has joined #linux-sunxi
tlwoerner has quit [Ping timeout: 255 seconds]
fkluknav has quit [Ping timeout: 240 seconds]
a|3x has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
fkluknav has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
aalm has quit [Ping timeout: 240 seconds]
aalm has joined #linux-sunxi
fkluknav has quit [Ping timeout: 248 seconds]
<freemangordon>
I get "_CREATE_GEM({height: 600, width: 1024, bpp: 32 buf_type: 0x0}) failed. errno: 22" - Invalid argument when starting X on with my A33 and mali binary driver, kernel is 4.11.12, mali driver is r6p2
netlynx has joined #linux-sunxi
<freemangordon>
kernel is mainline, no additional patches
<freemangordon>
any clue what I am missing?
<freemangordon>
MoeIcenowy: mripard: ^^^?
<freemangordon>
guess I am using the wrong kernel
<KotCzarny>
might be also leftover gl libs?
<freemangordon>
no, I pulled the ones from freeelectrons
<oliv3r>
Wizzup: wouldn be easier to open u-boot, and just gpio toggle those 'expected' pins with a multimeter or scope on those padS?
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
<Wizzup>
oliv3r: probably. yep.
<oliv3r>
:)
<oliv3r>
Wizzup: obviously i'm also very curious now as to what it is
<oliv3r>
my guess, would be either spi flash or I2C flash
<oliv3r>
if you figure out where the gnd and vcc pins are
dev1990 has quit [Quit: Konversation terminated!]
<Wizzup>
oliv3r: I already did, they match the usual spi flash
<oliv3r>
yeah but they also match usual i2c flash :(
<Wizzup>
ah.
<oliv3r>
pins 123 are address bits on i2c
<oliv3r>
4 is gnd, 5 is sda, 6 is scl
<Wizzup>
and 8 is vcc?
<oliv3r>
7 is the write protect bit
<Wizzup>
I don't have a scope at work, but I can take it to the hackspace and check later
<Wizzup>
or just do what you said wrt u-boot
<oliv3r>
multimeter works just as well for gpio toggle
<Wizzup>
yep
<oliv3r>
i do that quite often :)
<oliv3r>
it is often even easier then to do the pin-math
<oliv3r>
'what pin number was PH4 again'
<oliv3r>
but pin 5
<oliv3r>
and do a gpio toggle on all the I2C*_SDA pins
<oliv3r>
and follow then up with al the SPI*_MISO pins
<oliv3r>
i'm guessing its easist to make a list, and just toggle them all low
<oliv3r>
put on the probe, if it's low, then your good to start
<oliv3r>
toggle them all high, put the probe on
<oliv3r>
if it's high now, you know you got something
<oliv3r>
otherwise, you got nothing anyway
<oliv3r>
can see where those traces are going though of the CLK/MISO (or sda/scl)
<oliv3r>
and the mosi seems to be connected via some other layer or hidden via
<oliv3r>
making i2c more likley
<oliv3r>
123 seem to be NC, 56 are obviously traces, 6 also NC
<oliv3r>
the direction of those traces are moving away from the CPU however, which is a little odd
<oliv3r>
there's room for a power cap at pin 8
Mr__Anderson has joined #linux-sunxi
<Wizzup>
hmmm, well, I'll measure it tomorrow eve if I can :
<Wizzup>
:)
<Wizzup>
will follow those steps
<oliv3r>
:)
<oliv3r>
now i'm left with curiosity until tomorrow
<freemangordon>
Wizzup: still not, I have trouble forward-porting that patch. it uses external function that is static in mainline
<freemangordon>
I wonder why GEM is not created using DRM_IOCTL_MODE_CREATE_DUMB
popolon has joined #linux-sunxi
<Wizzup>
oliv3r: tablet is at work, I'm at home (just got home)
<oliv3r>
wizzup for i2c_sda: PL1, PL9, PE13, PH3, PH5 for spi_mosi: pa2, pc0,
<oliv3r>
ah :)
<Wizzup>
I'm going back to work at this hour ;)
<Wizzup>
I'm not*
<freemangordon>
Wizzup: got it working :), had to patch xserver-xorg-video-armsoc driver
<freemangordon>
not sure my patch is the correct one, will make a pull request on github and will see
<Wizzup>
freemangordon: cool
<mripard>
freemangordon: you cannot use a dumb buffer
<mripard>
a dumb buffer is only meant for scanout, and you have 0 guarantee that the GPU will be able to access it.
<freemangordon>
mripard: yep, though so. however, the code in that patch calls drm_gem_cma_create_with_handle which is exactly what drm_gem_cma_dumb_create calls. What is the difference? flags?
<mripard>
no, the difference is a matter of API semantic
<mripard>
and while the API has to stay the same, the code underneath can change
deskwizard has joined #linux-sunxi
deskwizard has quit [Changing host]
deskwizard has joined #linux-sunxi
<freemangordon>
mripard: ah, so I have to patch the kernel instead of patching xorg driver? what about changing struct drm_sun4i_gem_create to at least provide the full set of data (width, height, etc) to kernel?
<freemangordon>
so, instead of hacking kernel to export a static function, to be able to call drm_gem_cma_dumb_create from within custom IOCT handler
netlynx has quit [Quit: Ex-Chat]
Poeticode has joined #linux-sunxi
<mripard>
I have no idea what you mean, sorry
<mripard>
Isn't the patch you linked enough ?
<freemangordon>
it doesn't compile on upstream
<freemangordon>
because in upstream drm_gem_cma_create_with_handle is static
<freemangordon>
mripard: this is clear, it is just that I don;t see it accepted upstream. Thus I was thinking for a less hacky way of achieving the same. Like copying drm_gem_cma_create_with_handle code into sun4i_drv. Also I wonder how upstreamed drm drivers do it. Will try to find some spare time soon to see if something can be done.
chomwitt has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
tlwoerner has joined #linux-sunxi
chomwitt has quit [Ping timeout: 255 seconds]
chomwitt has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
<L29Ah>
have anyone made the a20 audio line in to work?