<anarsoul>
codekipper: btw, is there any way to rename lineout control? It has speaker connected to it on pinebook, and pulseaudio wants control to be named 'Speaker' in order to have 'Speaker' path
<wens>
that's unlikely to happen
<wens>
the controls are named after the pins on the SoC
<wens>
what is connected is up to the vendor
msimpson has joined #linux-sunxi
<anarsoul>
wens: OK, so how to deal with gpio-controlled amp then? :)
lemonzest has joined #linux-sunxi
<KotCzarny>
alsactl/alsamixer
<KotCzarny>
and proper driver
<anarsoul>
KotCzarny: driver has to know that there's a gpio to enable amp
<anarsoul>
sun4i-codec has a dt property for that and "Speaker" widget
<anarsoul>
KotCzarny: and no, it's not enabled using alsactl or alsamixer
<KotCzarny>
enable it at boot time?
<KotCzarny>
seems device specific
Ntemis has quit [Remote host closed the connection]
<KotCzarny>
btw. supersuspend on legacy kernels with Axx socs rock
<KotCzarny>
eh
<KotCzarny>
i'm jealous
<KotCzarny>
working os in less than 0.5s, almost no battery drain over night
<anarsoul>
KotCzarny: check sound/soc/sunxi/sun4i-codec.c, grep for allwinner,pa
<KotCzarny>
it is there, and?
<wens>
it's controlled through DAPM
<Wizzup>
KotCzarny: what is supersuspend?
<KotCzarny>
also, funny that it has _get_optional yet it errours out later
<wens>
which doesn't give you the option to manually mute it, when it shares the same output pins as a headphone jack
<KotCzarny>
wizzup: aw name for a suspend (but they've implemented pretty sweet modes, partial, mem, standby). ss is the one with greatest savings, with dram on selfrefresh
<Wizzup>
I see
leviathanch has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
<icenowy[m]>
KotCzarny: I think it's superstandby
<icenowy[m]>
not supersuspend
<KotCzarny>
right
<KotCzarny>
it's still early here
<icenowy[m]>
personally I prefer to implement normal standby first on mainline
<KotCzarny>
with or without arisc?
<icenowy[m]>
wo
<KotCzarny>
how would you wake up then?
<icenowy[m]>
I think the AW BSP code will just be waken up after a WFI is done ;-)
paweld has joined #linux-sunxi
<KotCzarny>
hmm, uboot should autodetect ram or it's hardcoded? (a13)
<paweld>
Hi! I was asked to implement firmware upgrade function in allwinner's u-boot (2011.09) on SOM from VStar which has A33 (sun8iw5p1). We're running Android 4.4.2 (provided by VStar / Allwinner). The idea is, if we would ever want to upgrade firmware, we won't have to force our customers to use Phoenix Suite. We are running from eMMC. It would be best to read System.img from USB (pendrive).
<KotCzarny>
personally i've just added rescue ramdisk with online updater (on h3droid)
<paweld>
Though I have found some issues, which are currently blocking me : 1. We don't have USB drivers; 2. There are no support for EXT4 filesystem; 3. I couldn't find any example how to proceed with system update (except the one from Digi international, custom function in their U-boot).
<pmpp>
no wonder it needs upgrading then ...
<paweld>
Could it work on A33 as well?
<KotCzarny>
paweld: well, i'm using it for my boards specifically, but since it's linux based you can probably implement your own (assuming you build your own images)
<pmpp>
with mainline uboot probably
yann has quit [Ping timeout: 252 seconds]
<paweld>
So, would it be possible to run Android (from Allwinner/VStar) on mainline U-boot using mmc? By possible I mean "work almost out of the box" since I'm all alone on this and can't spend too much time on this issue, because of other tasks.
<KotCzarny>
it's tough luck, because linux-sunxi is all about mainlining (uboot and kernel), with legacy code used only for a source of info
<paweld>
Is there any success-story with mainline U-Boot, Kernel, Android and A33? From what I've read on linux-sunxi wiki - support for A33 is very limited and I just don't know where to start. Basically, we need this SOM board for GUI, networking and uart communication with MCU board.
<KotCzarny>
this should be primary source of your information
<paweld>
And I'm bit terrified to put user-friendly device on market with such horrible update procedure (I assume that we'd need at least one).
<KotCzarny>
but if you plan to use android, you are stuck with legacy kernel
<KotCzarny>
you might get away with mainline uboot though
<paweld>
So, just try to use mainline U-boot together with legacy kernel and android?
<KotCzarny>
and your own rescue system
<paweld>
So, it's probably impossible to do in ~2-3 weeks without previous experience with such things?
<beeble>
or mainline with fastboot for the android way(tm)
<KotCzarny>
if you are a quick learner
<paweld>
Fastboot isn't just usb protocol? We would have to connect our device to PC, right?
<beeble>
yes, if you don't want to do that booting a rescue system and flashing everything ist the most straight forward way
<paweld>
Yes... We need updates from USB pendrive (because some of our customers might not want to connect the device to the Internet, for many reasons and the device is too big to move or it doesn't stand next to PC). Thank you for your help, I'll try with mainline U-boot then!
uwe__ is now known as uwe_
<KotCzarny>
hmm, latest uboot has CONFIG_SYS_BOOTM_LEN broken
<KotCzarny>
when set in defconfig it gets lost
<KotCzarny>
still, trying to bootm with large kernel complains to increase it
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
junnie_ has quit [Ping timeout: 264 seconds]
BenG has joined #linux-sunxi
BenG83 has quit [Ping timeout: 268 seconds]
BenG is now known as Guest28395
Guest28395 is now known as BenG83
sr-digitronic has joined #linux-sunxi
sr-digitronic is now known as basxto_
yann has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
<icenowy[m]>
I think BSP has its fastboot implementation.
dddddd has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
fkluknav has joined #linux-sunxi
pgreco has joined #linux-sunxi
fkluknav has quit [Ping timeout: 264 seconds]
chlorine_ has joined #linux-sunxi
fdcx has quit [Ping timeout: 248 seconds]
chlorine has quit [Ping timeout: 256 seconds]
fdcx has joined #linux-sunxi
libv_ has joined #linux-sunxi
afaerber has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
clemens3 has joined #linux-sunxi
<embed-3d>
tkaiser: The H5 needs an other formula if the temperature gets over 70°C. Do you see this often/sometimes in armbian? I'm asking this because I'm not shure if I should handle this case in my ths wip driver.
<mripard>
embed-3d: we're not really expecting you to support all of the SoCs from day 1 either
<mripard>
if you want to support only one or two of them, it's totally fine as well
leviathanch has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
dddddd has quit [Ping timeout: 240 seconds]
dddddd has joined #linux-sunxi
reinforce has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine_ has quit [Read error: Connection reset by peer]
<embed-3d>
mripard: That's clear! My first patchseries for this will go out hopfully today and will only contain H3 and A83T since I have hardware for those and I tested them. H5, A64 and A80 support will be added later.
<mripard>
embed-3d: awesome :)
<KotCzarny>
where are you taking formulas from?
willmore has quit [Read error: Connection reset by peer]
<embed-3d>
KotCzarny: From the bsp's
jbrown has joined #linux-sunxi
<KotCzarny>
bsp as in aw code or aw manual?
willmore has joined #linux-sunxi
<icenowy[m]>
manual is not bsp ;-)
<embed-3d>
The temp formulas are from aw code. I compared them with the datasheet and only that from H3 is wrong.
<icenowy[m]>
code is
<KotCzarny>
icenowy, in a way it is ;)
<sunxi_fan>
hi, i have a libMali.ko r6p2 "someway" running on a sunxi-next 4.15.rc2 configured as dual head DRM/KMS setup (LCD + HDMI going on/off) and i have to say i'm a bit puzzled.. i'm writing to get a feedback about it..
<icenowy[m]>
mripard: but we should consider day 2,3,etc since day 1
tllim has joined #linux-sunxi
<sunxi_fan>
practically speaking, if the HDMI is connected at kernel boot, i have correctly a dual screen and kmstest shows two different test cards, but any Qt5 example app on eglfs_mali platform is completely messed up (flickering and so on..), send you a shot later,,
<sunxi_fan>
if i link the HDMI tv set after the kernel has booted on LCD only, the HDMI gets a resolution 800x600 (where the LCD was 800x480), it's a mirror of the LCD screen and the Qt app is running ok but..
<sunxi_fan>
.. in the HDMI screen the last 120 rows are the head of the buffer, with a very annoyinf clickering effect (on the last 120 rows only.. funnily).
<sunxi_fan>
the CMD is this one: QT_QPA_DEBUG=1 QT_QPA_PLATFORM=eglfs QT_LOGGING_RULES="qt.qpa.*=true" QT_QPA_EGLFS_INTEGRATION=eglfs_mali FRONTBUFFER_LOCKING=1 /usr/bin/CinematicExperience-demo
<sunxi_fan>
anyone ever tested OpenGL mali binary blob on dual head DRM/KMS setup?
<sunxi_fan>
what's the supposed behaviour when linking / unlinking externa displays? are we in uncharted waters in terms of usability? what could be the best/shorter/most effective path for a consistent behaviour (whatever that means.. anyway! .-)
<sunxi_fan>
i'm of course talking of an embedded environment. not in a desktop one X/wayland,,, where the desktop manager takes care of display arrangement..
cnxsoft has quit [Quit: cnxsoft]
<icenowy[m]>
what blob variant did you use?
<sunxi_fan>
the r6p2 from free-electrons ..
<icenowy[m]>
oh so you used fbdev variant?
<sunxi_fan>
yes, yes. fbdev..
<icenowy[m]>
fbdev cannot manage display.
libv_ is now known as libv
<sunxi_fan>
i know.. but do you know of other "blobs" i could test on an embedded environment. what's the "Best way" (TM) for a Qt full screen application?
<sunxi_fan>
i've heard of the "gbm" variant, some months ago. but didn't see and release.. and i don't really know what "backend" on the Qt side?
<sunxi_fan>
it would be the "eglfs_kms" Qt platform backend. right? i'm really not very clear about the "long-term best" scenario for Qt on Linux embedded graphic stack!
<sunxi_fan>
BTW are there any talks / meeting about it at next Fosdem meeting?
<sunxi_fan>
i know there's r8pXXX versione floating for some the rockchip
<sunxi_fan>
.....but i don't know if these "franken-blobs" are worth the time to be tested on so different HW!!
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 264 seconds]
aalm has quit [Ping timeout: 256 seconds]
chlorine has quit [Ping timeout: 265 seconds]
chlorine_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
chlorine_ has quit [Read error: Connection reset by peer]
chlorin__ has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorin__ has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-sunxi
tl_lim has quit [Quit: Leaving]
megi has joined #linux-sunxi
SP7RT has quit [Ping timeout: 260 seconds]
MX-Master has joined #linux-sunxi
<MX-Master>
KotCzarny: tried to change clock settings of ARISC core before loading the blob, but without any success. Tried to write the ARISC parameters blob after writing the ARISC code blob - no effect.
<KotCzarny>
uboot version is 2017.07-00494-g19d1f1a-dirty
dave0x6d has quit [Quit: Connection closed for inactivity]
junnie_ has quit [Ping timeout: 248 seconds]
chomwitt has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
<smaeul>
wasutton3: what's the question?
<smaeul>
> Don't ask to ask. Just ask and wait!
<wasutton3>
smaeul, i'm trying to get an SPI 802.15.4 radio working on the pine64, and i think i just found part of my issue. let me try something real fast and ill be back.
kloczek has quit [Remote host closed the connection]
MX-Master has quit [Quit: Leaving]
paweld has quit [Quit: Page closed]
clemens3 has quit [Ping timeout: 264 seconds]
rasp has joined #linux-sunxi
kloczek has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
basxto_ has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
chlorine_ has quit [Ping timeout: 240 seconds]
chlorine has quit [Ping timeout: 240 seconds]
<KotCzarny>
so, what was the way to debug "Starting kernel ..." ?
<Wizzup>
has anyone tried to build u-boot recently? it fails to build for me because my default python is python3...
<Wizzup>
and then it builds a python3.4 pylibfdt
<Wizzup>
methinks scripts/dtc/pylibfdt/Makefile needs a good s/\$PYTHON/python2/ :)
fl_0 has quit [Ping timeout: 256 seconds]
<beeble>
Wizzup: works for me with python3.4
fl_0 has joined #linux-sunxi
<Wizzup>
beeble: not here, the pyftd thing has #/usr/bin/env python2
<Wizzup>
s oit builds 34 module and tries to load it from 27
<beeble>
ah, i still have 2.7 installed in parallel
<beeble>
Wizzup: Python 3.5.3 but i have only an alias set to python3
clemens3 has joined #linux-sunxi
<smaeul>
KotCzarny: assuming the mmio address of UART0 is correct, it should
<Wizzup>
so how do you build then, with PYTHON=python2 ?
<beeble>
no, just make (did a git clean -dxf before)
<Wizzup>
what tag are you on?
<Wizzup>
I think I checked out the release of 2018.01
<beeble>
ah
<beeble>
ok
<beeble>
i see now
<beeble>
it ignores my alias
<KotCzarny>
smaeul: uboot uses serial@01c28400, but i've tried that addr too without success
<Wizzup>
beeble: do you also have the problem?
<Wizzup>
I'm confused
<Wizzup>
actually I'm on c761a7e29d703d60208585bb7d8415e00aa22556
<jernej>
beeble: did you have time to test hdmi on A80?
<smaeul>
KotCzarny: then `#define DEBUG` at the very top of the u-boot source files relevant for loading Linux, and see if anything jumps out at you
<KotCzarny>
i only get:
<KotCzarny>
Starting kernel ...
<KotCzarny>
DRAM: 256
sunxi_fan has left #linux-sunxi [#linux-sunxi]
fl_0 has quit [Ping timeout: 256 seconds]
<miasma>
Wizzup: did you solve the issue? it seems to assume you have python2. i made a bash script that calls python2 when you call 'python'. since arch defaults to python3
<beeble>
Wizzup: sorry my fault, i do have an issue. due /usr/bin/env used my python2 default instead of my python3 alias
<Wizzup>
miasma: sed -i s/\$PYTHON/python2/ scripts/dtc/pylibfdt/Makefile
JohnDoe_71Rus has quit [Ping timeout: 256 seconds]
<beeble>
jernej: sorry didn't find time this week
<miasma>
Wizzup: that works nowadays?
<Wizzup>
miasma: works for me?
<miasma>
ok
<Wizzup>
btw, I might have swapped the sed args
<Wizzup>
but you get the idea
<jernej>
beeble: no problem, just curious
<Wizzup>
just replace $PYTHON with python2
<miasma>
i think there used to be other problems with that earlier. maybe something here in the logs
kaspter has quit [Quit: kaspter]
fl_0 has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Quit: Leaving]
Putti has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
yann has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
Gerwin_J has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lemonzest has quit [Quit: Quitting]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
dave0x6d has joined #linux-sunxi
megi has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
<rasp>
on an h2+, having mmap'ed 0x1c20000 to somewhere and adding 0x800 I've got the PA_CFG0, setting a pin as in or out works and is also shown as changed if I change the direction viaa sysfs, however writing to or reading from that base+0x10 renders nothing, any idea what I'm doing wrong here ?
<rasp>
i.e. just set PA1 as out and toggle.
afaerber has quit [Quit: Leaving]
Poeticode is now known as ImoutoCodes
<wasutton3>
so i think im trying to understand appending a device to a dts file.
ImoutoCodes is now known as Poeticode
<wasutton3>
reset-gpio = <&pio 3 14 1>; means im assigning the 14th pin of bank 3 to the variable.
anarsoul|2 has quit [Remote host closed the connection]
anarsoul|2 has joined #linux-sunxi
<smaeul>
kilobyte: thanks, so there were 0x10002284c3c1e64 ticks between ts_prev and ts, meaning it (most likely) jumped 0x100000000000000 ticks
<smaeul>
the patch only handles jumping forward and immediately back (basically indeterminate bits while carrying) -- if it jumps forward and stays, then it's not rejected
<kilobyte>
are the jumps you've encountered before small?
<smaeul>
and unfortunately there's no logging "here's CNTVCT before the jump, and here's CNTVCT after the jump"
<smaeul>
kilobyte: no, I've seen 100 year jumps too
<kilobyte>
all I've noticed were to 2113 (or 2112 months ago), never to any other year
<atsampson>
my Pine64 is quite fond of jumping to 2153...
<kilobyte>
atsampson: oh, so it's possible it depends on a particular piece of hardware