<suprothunderbolt>
i'm not sure what I should be looking for, but I want to enable the master clock on the master clock pin on a Pine64. On other platforms I've done this with a enable line in the device tree.
_whitelogger has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
megi has quit [Ping timeout: 245 seconds]
lurchi__ is now known as lurchi_
Ultrasauce has quit [Quit: Ultrasauce]
<willmore>
OUI is the Organizational Unique Identifier (first 24 bits). Then the whole thing is the Extended Unique Identifier. You can call the last 24 bit part the extension identifier.
tllim has joined #linux-sunxi
cch has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
_whitelogger has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 246 seconds]
<suprothunderbolt>
does the legacy BSP support TDM I2S? I'm wondering if that's where I should start for getting it working on mainline.
grosso has quit [Ping timeout: 255 seconds]
_whitelogger has joined #linux-sunxi
random_yanek has quit [Ping timeout: 246 seconds]
<suprothunderbolt>
is there a way to validate a DTS overlay before running it? I want to check if all my references resolve. I'm not sure if I've understood how overlays are meant to work
captainigloo has quit [Ping timeout: 258 seconds]
random_yanek has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
KotCzarny has quit [Ping timeout: 246 seconds]
captainigloo has joined #linux-sunxi
shfil has quit [Quit: Connection closed for inactivity]
<lavamind>
bbrezillon: I've compiled the nand/chip kernel and added my existing CHIP partitions in slc-mode in the DT, but when MTD attemps to create the partitions it panics: kernel BUG at fs/sysfs/file.c:328!
<lavamind>
I suspect this is because those partitions were created in MLC mode, but is there a way to convert them or will I need to create entirely new partitions on the NAND
<lavamind>
my (stock, as shipped by NTC) partitions probably don't have a pairing scheme defined?
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<cch>
Is there a Chinese irc channel?
<[TheBug]>
sure, I am sure there are plenty of Chinese irc channels... just I doubt on this topic with these people
<[TheBug]>
Though the way you asaked that seemed a bit odd, it would be like me asking, "Is there an American irc channel"
camus has joined #linux-sunxi
<[TheBug]>
which wouldn't make much sense either
kaspter has quit [Ping timeout: 255 seconds]
camus is now known as kaspter
<cch>
sorry for making this confusion. What I want to know is there an Chinese irc channel for linux-sunxi. e.g. linux-sunxi-cn
<[TheBug]>
I think your asking if there is a Chinese speaking irc channel, in which case I would point out to you that such things as linux-sunxi take a lot of community working together and that there are likely many Chinese speakers here, however, business here is conducted in English so that all can participate
<DonkeyHotei>
many of the main people in this channel are in china
lynxis has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
random_yanek has quit [Ping timeout: 246 seconds]
random_yanek has joined #linux-sunxi
nuuuciano_ has quit [Ping timeout: 255 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 250 seconds]
nuuuciano_ has joined #linux-sunxi
nixdork has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
<MoeIcenowy>
cch: If you think HiSilicon Kirin are "国产", then Allwinner are
KotCzarny has joined #linux-sunxi
agraf_ has joined #linux-sunxi
agraf has quit [Ping timeout: 244 seconds]
agraf_ is now known as agraf
random_yanek has quit [Ping timeout: 250 seconds]
nuuuciano_ has quit [Ping timeout: 250 seconds]
<cch>
MoeIcenowy: thanks
<suprothunderbolt>
does anyone know if TDM works with the BSP code? It appears to on reading the code. I assume I'll just need to port this to mainline.
<suprothunderbolt>
I'm looking at longsleep's github
random_yanek has joined #linux-sunxi
<cch>
MoeIcenowy: I have modified the sunxi_sid.c in linux kernel to support write operation. I have tested with NV1, the write operation finished but the bits are not changed (all bits are zero always). I am working
<bbrezillon>
lavamind: yep, you probably have an Hynix chip
<bbrezillon>
I didn't bother porting this pairing scheme, but it's defined in the nand/mlc branch
grosso has joined #linux-sunxi
random_yanek has quit [Ping timeout: 255 seconds]
f0xx has joined #linux-sunxi
mhlavink has quit [Quit: No Ping reply in 180 seconds.]
plaes has quit [Ping timeout: 245 seconds]
igraltist has quit [Ping timeout: 245 seconds]
plaes has joined #linux-sunxi
plaes has joined #linux-sunxi
plaes has quit [Changing host]
igraltist has joined #linux-sunxi
random_yanek has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
dirbaio has quit [Ping timeout: 245 seconds]
yann has quit [Ping timeout: 268 seconds]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
gamiee has quit [Ping timeout: 255 seconds]
dirbaio has joined #linux-sunxi
cch has quit [Ping timeout: 246 seconds]
mzki_ has joined #linux-sunxi
mzki has quit [Ping timeout: 245 seconds]
chomwitt has quit [Ping timeout: 245 seconds]
BenG83 has quit [Ping timeout: 246 seconds]
chomwitt has joined #linux-sunxi
wwilly_ has quit [Quit: Leaving]
wwilly has joined #linux-sunxi
tnovotny has joined #linux-sunxi
paulliu has joined #linux-sunxi
yann has joined #linux-sunxi
tnovotny has quit [Ping timeout: 246 seconds]
tnovotny has joined #linux-sunxi
wens has quit [Remote host closed the connection]
jaganteki has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 245 seconds]
wens has joined #linux-sunxi
<wens>
MoeIcenowy: seems my pine h64 reboots just fine as well :/
<wens>
MoeIcenowy: using latest ATF and U-boot
<fALSO>
=)
cch has joined #linux-sunxi
victhor has joined #linux-sunxi
<cch>
curlybracket: I have tried the code your provided. Build it with latest sunxi-tools in my lattop, and boot the board with uboot been pressed
<cch>
curlybracket: Does VDD_EFUSEBP pin needs to be connected to GND or 3.3V ?
airwind has joined #linux-sunxi
<libv>
so there is no info on how to enable kms on the wiki?
<libv>
do we even want users for that?
<wens>
libv: what sort of info do you have in mind? kconfig options? xorg config?
<libv>
well, it does not work out of the box on my now 2 week old kernel on the banana pi m1
<libv>
i am going to have a poke at the dts, and i need the driver built as modules anyway
<libv>
and i am not sure whether it is devicetree, or the fact that there was simplefb loaded at this point
Mangy_Dog has joined #linux-sunxi
<libv>
and then i thought "i doubt that there is even a wiki page to at least assure people that it is supposed to just work"
<libv>
and no
<libv>
or yes
<libv>
this is not hard to do people, and makes a massive difference and does not cost much in the way of time
<libv>
but it requires that you desire to have actual users
<KotCzarny>
i suspect it's up to actual users to contribute too
<KotCzarny>
if it just worked, no one batted the eye
<KotCzarny>
if it broke at some point, well
<wens>
reboot doesn't work on my orangepi lite 2 :/
<libv>
KotCzarny: users will not do the initial work
<libv>
they cannot be expected to do so
<libv>
they also should not be responsible for changes made by developers
<libv>
the core question is, do you want people to use your code, yes or no?
<KotCzarny>
i personally just use simplefb
<KotCzarny>
which 'just works'
<Wizzup>
weird, kms worked out of the box for me last time I tried
<libv>
if you do, then you should provide them with a minimal amount of help
<libv>
simplefb came up for me as well
<libv>
simplefb was another of those typical libv stories... people only wrote it for rpi, and then fooled themselves that it would really be simple
<libv>
until someone tried to use it for hw that actually was being controlled by the arm core
<libv>
and things like power and clocks were needed
<libv>
2.5x lkml emails than there were loc
<KotCzarny>
then it was up to the uboot to set it up, and linux doesnt touch anything
<KotCzarny>
a bit off-topic, but it's weird, that some things have code in both kernel and uboot, some only in kernel, and som only in uboot
<libv>
KotCzarny: i wrote the initial hdmi simplfb implementation in 2014, and expanded it to know about clocking, so the kernel would not go and automatically disable the clocks for an engine which actually was in use
megi has joined #linux-sunxi
wens has quit [Ping timeout: 244 seconds]
<libv>
before that point, simplefb only existed for the rpi
<libv>
and the rpi still had most things controlled by the videocore dsp then
<libv>
another bubble i had the pleasure to burst, with all the repercussions that came with that
<libv>
anyway, kms does not always just work out of the box
<libv>
but no-one involved with bringing up kms and upstreaming it ever thought about writing anything up, so that users actually have a starting point
<libv>
(some) normal users will fix small errors
<libv>
they cannot be expected to write the whole thing
<libv>
throwing something in the wiki barely costs any time, especially compared to bringing anything upstream
<libv>
what gives?
BenG83 has joined #linux-sunxi
<karlp>
it's a conspiracy against you personally. there's actuall docs, but they're hidden from you.
<libv>
heh
<Mangy_Dog>
Need a tidbit of help maybe, Im using the JQ8400 audio module in my tricorder project, its serial controlled but is set to 9600 speed. The basic datasheet doesnt say anything, but does anyone know of a command to raise the datarate?
<buZz>
libv: what repercussions were there for adding foss to rpi?
<libv>
buZz: nothing as direct as becoming as unhireable as with lima
<libv>
but there was some nasty crap thrown, and it added to my general image of being a nuissance
<buZz>
ah nah man, you're a legend
<buZz>
dont let ppl tell you otherwise
<libv>
and yet i get to teach embedded idiots how to use git :)
<libv>
and spend every minute i get back to "normal" open source people on how they fail to understand some trivial and basic things, like, just throwing something in a wiki so you do not have to go and figure things out from scratch the next time
<libv>
(and so that others can help keep things up to date)
<buZz>
we know and we appreciate that
wens has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
<libv>
heh. rsyncing lib/modules/ to the banana-pi:/root/ kills pub key authentication as /root/ is chowned to the user initiating the rsync (top level only)
<KotCzarny>
depends on command line
<libv>
yeah, but that took a few minutes to figure out
<libv>
and i have never run into that one before
<libv>
--chown made no difference it seems
<KotCzarny>
best to use /tmp/ for foolin' around
<KotCzarny>
and you can always run rsync with '-i'
<libv>
which would then chown /tmp/ :)
<KotCzarny>
so you will see what it's doing
<KotCzarny>
*is it
<libv>
ah, yeah, good point
<libv>
running rsync to root@ has sideeffects it seems
<karlp>
but now it's "the way" and can never be changed :)
<mru>
sometimes it's what you want
<libv>
it does seem quite obscure
<KotCzarny>
mru, i would assume then dropping final slashes to achieve that, no?
<libv>
i will poke the author of csync, who lives just 50m away, and see what he knows/thinks about this
<KotCzarny>
ie. difference between dir and contents of that dir
<mru>
"rsync foo/ ..." is equivalent to "rsync foo/. ..."
nuuuciano_ has quit [Ping timeout: 250 seconds]
<KotCzarny>
mru, what about ... ?
<KotCzarny>
because it's the thing that got broken in this case
<mru>
trailing slashes on the destination don't matter
<mru>
it's all in the man page
<KotCzarny>
When not using "/" at the end of destination, rsync will create a folder with the last destination folder name and paste the data inside that folder
<KotCzarny>
but hmm
<KotCzarny>
testing it proves otherwise
<KotCzarny>
funny.
<KotCzarny>
unless it doesnt show with -n
<mru>
the trailing / is only significant on the source
<mru>
"rsync -a foo bar" makes a copy of foo at bar/foo
<KotCzarny>
yeah, just tried it in both combos
<mru>
"rsync -a foo/ bar" copies the contents of foo into bar
<mru>
it may help to think of "foo/" as "foo/."
<mru>
thus "rsync -a foo/. bar" should copy foo/. into bar/.
<EmilKarlson>
rsync -aHAX --delete
<mru>
just as "rsync -a foo/baz bar" copies foo/baz into bar/baz
<libv>
searching rsync bugzilla for "owner" and "chown" did not turn up anything
<KotCzarny>
mru, but in this case, it also chown 'bar'
<KotCzarny>
which is unexpected
<mru>
yes, because bar/. is the same as bar
<mru>
totally expected
<KotCzarny>
'copy z into x' logically doesnt say anything about touching 'x', that 'z/.' thing is the trick
<KotCzarny>
maybe it could be added so 'z' is different from 'z/.' :P
<KotCzarny>
would confuse few folks more
<libv>
yeah
<libv>
it is desired behaviour
<libv>
and the slash is indeed the key
<libv>
mru: you're right
<libv>
and no credit for me as i messed up slashing
<libv>
rsync -a dir/ root@host:/dir/ has to chown root@host:/dir to match
<libv>
rsync -a dir root@host:/dir/ creates root@host:/dir/dir and does not alter the top level
<KotCzarny>
new day, new tricks
<libv>
or do not rsync to root@ :)
<KotCzarny>
or always test with -ni beforehand
<libv>
-i will not warn you about this specific thing
<KotCzarny>
it will
<KotCzarny>
.d..t.o.... ./
<libv>
oh, right
<KotCzarny>
means it will change things
* libv
scrolls up and reads that line again in his buffer
<libv>
right
dddddd has joined #linux-sunxi
<libv>
ah, and the reason why chown did not work is because i wrote root.root instead of root:root
<libv>
which was very daft it seems
<libv>
chown happily accepts the ., but i have been wrongly using that for a long time it seems
linkmauve has left #linux-sunxi [#linux-sunxi]
<KotCzarny>
lol
<libv>
*sigh* back to poking kms
<KotCzarny>
i guess that's because you can have username with the dot
<KotCzarny>
but then it should shout about non-existing user
<mru>
"The BSD syntax user[. group] was changed to user[: group] in this volume of POSIX.1-2017 because the <period> is a valid character in login names"
<libv>
i would first have to add a user to the bpi rootfs :)
<libv>
but that does indeed seem like a very recent implementational change
<libv>
what a load of bullshit, https://wiki.debian.org/KernelModesetting, "Kernel Mode Setting (KMS) provides faster mode switching for X and console. It also provides native-resolution VTs on some laptops and netbooks which, prior to this, would use some standard mode, e.g. 800×600 on a 1024×600 panel."
<mru>
guess they forgot about vesafb
<libv>
i am glad that it is no longer claimed to be flicker free, which is what keithp was claiming was the big reason to put modesetting in the kernel in 2007
<mru>
exposing hardware registers directly to userspace is obviously not great from a security viewpoint
<libv>
as he then proceeded to break the intel modesetting code and spent a few 100ms showing uninitialized ram content when starting X
<KotCzarny>
seeing ram is always nice
* KotCzarny
remembers having fun with it on A500
<libv>
it totally freaked out lower management at suse when we were close to release of an opensuse version
<libv>
as people remember when bleeding panels could ruin panels back in the 90s
gamiee has joined #linux-sunxi
<libv>
nobody did go and fix X to unsync only after ram content is valid
<libv>
instead a memset was added
<MoeIcenowy>
mripard: is it possible to workaround some pixel rows of the screen hidden by the device shell via DRM?
<MoeIcenowy>
on the PineTab around 4 rows of pixels at top are invisible because it's under the black side
* mru
would fire the case designer
<MoeIcenowy>
seems that the black side is not part of the case, but the touch panel
<mru>
well, someone should be fired
msde has quit [Remote host closed the connection]
<libv>
MoeIcenowy: how does the bsp kernel fix that?
<MoeIcenowy>
libv: it's also not fixed
<libv>
ok
<MoeIcenowy>
but TL says that they're going to replace the touch panel
<libv>
that is going to be a pain to work around
<libv>
as it will permeate through several things
<lavamind>
bbrezillon: yeah, its a Hynix chip, "H27UCG8T2ATR-BC 64G 3.3V 8-bit"
<lavamind>
do I need to put all patches from nand/mlc on top of chip/nand ? or just a select few ?
<lavamind>
there seem to be quite a lot
<MoeIcenowy>
is there any cooling suggestion for a Pine H64 model B in a plastic case?
<MoeIcenowy>
I'm using it to run distro-building task
<MoeIcenowy>
and it throttles
Rafael1980 has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
<MoeIcenowy>
martinayotte: BTW it seems that no any revision of Pine H64 has the WDOG reset issue
<wens>
MoeIcenowy: do you have any H6 Orange Pis that you could test WDOG on?
<lavamind>
ok I see there's hynix-specific patches in there, I can probably figure it out
<bbrezillon>
lavamind: just select/port those adding the pairing scheme for Hynix
<libv>
TCON
<libv>
0
<libv>
Control
<libv>
Register
<MoeIcenowy>
wens: no
<libv>
bah
<MoeIcenowy>
but I have a RP-H6B
<lavamind>
bbrezillon: yes, thanks!
<libv>
MoeIcenowy: there's a start delay in that register
<wens>
MoeIcenowy: lose the plastic case, or if it's an assembled one, at least the sides
<libv>
only 5 bits, and probably cannot be negative and it is most likely measured in pixels and not in lines
<libv>
you can try faking the fb address and resolution, but that's probably a lot of hassle
<lavamind>
bbrezillon: if I get it working can I PR the chip/nand branch ?
<lavamind>
also the devicetree is missing a nand partition scheme, it should probably define the default one from ntc ?
<libv>
directly connected panels are DE driven, unlike CRTs which are sync driven, so it is probably not possible to adjust blanking to match
<MoeIcenowy>
wens: maybe I should switch to metal case?
<MoeIcenowy>
I think I can ask TL for one
<lavamind>
those who repartitioned their CHIP are probably familiar with DT and can adjust it themselves
<MoeIcenowy>
although it will be for Rock64, not Pine H64
<MoeIcenowy>
BTW the internal PHY of H6 is really making me headache
<MoeIcenowy>
seems that RP-H6B resets by mw `030090b8 0x10 ; mw 030090b8 0x11` in U-Boot
<bbrezillon>
lavamind: please upstream the patches
<MoeIcenowy>
maybe I should upload the RP-H6[BC] schematics to the wiki
<MoeIcenowy>
as someone already added this board
<bbrezillon>
lavamind: I don't take PRs on my branches, as these are just dev branches
<wens>
MoeIcenowy: what's the plastic case then?
<MoeIcenowy>
wens: just an ordinary RPi case ;-)
<MoeIcenowy>
with power jack modded to insert 3.5/1.35 DC jack
<lavamind>
bbrezillon: upstream... the the linux kernel? oh my that would be quite new to me !
<MoeIcenowy>
lavamind: it's a new world ;-)
<lavamind>
guidance*
<lavamind>
I'm happy to help with some guidage, though
<lavamind>
anyway, I have to make it boot first !!
<wens>
MoeIcenowy: those suck :p the libretech one with the fan is nicer
afaerber has joined #linux-sunxi
<MoeIcenowy>
wens: so seems that only OPis are affected by WDOG issue?
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
<MoeIcenowy>
wens: open the case seems does no help...
<MoeIcenowy>
will I need some heatsink or even fan?
<MoeIcenowy>
you know, there could not be wind in my room ;-)
<wens>
heatsink would help a little bit with open ventilation
<MoeIcenowy>
but there's no
<MoeIcenowy>
maybe I should hack the trips in DT to get a higher temperature? (sounds something dangerous
<MoeIcenowy>
currently the "passive" trip is 75C, and Linux seems to be keeping this temperature well
<MoeIcenowy>
"hot" is 90C and "critical" is 100C
airwind has quit [Quit: airwind]
lurchi_ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
<megi>
MoeIcenowy, wens: Orange Pi 3 resets with the R_WDOG fine
<MoeIcenowy>
megi: but no w/ regulator WDOG?
<angelo_ts>
hi, could some good soul help me enabling a wm8804 in H3 (similar orange-one) devicetree ? i prepared i2c node, still not visible btw
a|3x has quit [Ping timeout: 268 seconds]
<angelo_ts>
i think i miss the pcm (i2s) interface node, to be linked to i2c node
<megi>
MoeIcenowy: not with what's mainline in ATF
<megi>
or u-boot
<MoeIcenowy>
Pine H64 and RP-H6B reboots well w/ mainline U-Boot
<megi>
Interesting, but Orange Pi 3 just hangs with both
<megi>
I really don't see why
<megi>
What's the difference
<KotCzarny>
something still kicks the wd?
<megi>
no, it hangs
<megi>
after timeout
<megi>
instead of reboot. uart output stops half-way through. that's how I know
<KotCzarny>
upload some arisc code to debug just before stopping wd?
<megi>
debug what? :)
<KotCzarny>
registers, of course
<megi>
there's quite a lot of them
<KotCzarny>
for h3/h5 i wrote me tiny arisc console
<KotCzarny>
it's trivial
<megi>
I tried obvious things, like setting RVBARADDR to BROM start
<megi>
but nothing
<KotCzarny>
does opi3 have some cpu voltage regulator?
<megi>
yes
<KotCzarny>
in h3 era it was hanging when it was in idle state before reboot, but uboot set cpu to 1008
<KotCzarny>
so it was undervolted heavily after reboot
<megi>
hmm
<megi>
nice idea
<KotCzarny>
try setting cpu to performance governor
<KotCzarny>
just befor reboot
<megi>
no dice, that's my deafult now
<megi>
so that will probably not be the issue
<MoeIcenowy>
megi: I think the RVBARADDR only apply to A64
<megi>
It's in H6 manual too
<KotCzarny>
megi, maybe it reboots to fel mode? :>
<megi>
perhaps CPU PLL fails during reboot, and it may help to change the frequecy to the default first
<megi>
just like there were issues with CPU PLL in the past when changing between some freqeucnies
<megi>
what's the top frequency in OPP for H64?
<MoeIcenowy>
megi: 1488MHz for my usage
<KotCzarny>
btw. can uboot do reset?
<MoeIcenowy>
I think some Armbian people overclock to 1.8GHz
<megi>
but I guess the reset would work in u-boot, as u-boot keeps the default frequency
<megi>
but it doesn't work in u-boot either
<MoeIcenowy>
then should not be the freq problem
<megi>
yeah
<megi>
I'm just glad R_WDOG works :)
<megi>
and that suggests it's not a frequency/PLL issue too
<megi>
haha, I feel like dr. House
<KotCzarny>
drugging yourself?
<megi>
hahahaha
<megi>
even funnier
shfil has quit [Quit: Connection closed for inactivity]
<megi>
I meant the differential diagnosis, but yeah, it may come to that too
<KotCzarny>
compare dts files ?
<MoeIcenowy>
I asked Wink
<MoeIcenowy>
KotCzarny: I remember martinayotte did image replacement experiment
<MoeIcenowy>
it's HW-related issue
<KotCzarny>
but why would it fail in warm-reboot
<MoeIcenowy>
I'm trying to do a diff on the schematics
<megi>
I tried rebooting bia arisc
<megi>
by holding the resets and releasing
<megi>
didn't work either
<MoeIcenowy>
but it looks like they are from the same parent ;-)
<MoeIcenowy>
(I doubt the parent is AW ref design
<KotCzarny>
MoeIcenowy: then it would be easier to find the differences
<KotCzarny>
:)
<MoeIcenowy>
I found no meaningful differences
<KotCzarny>
megi: bump voltage before reboot?
<megi>
it's already bumped up, by using the top OPP
<megi>
also R_WDOG works
<MoeIcenowy>
even the component ref label is the same
<megi>
remember
<MoeIcenowy>
on the two schematics
<megi>
with the same voltage/freq conditions
<MoeIcenowy>
e.g. AP-NMI has a 1nF C to GND
<MoeIcenowy>
it's labelled CC10 on both OPi1+ and Pine H64
<MoeIcenowy>
experienced Allwinner developer should discover boot to FEL ;-)
<megi>
:D
<KotCzarny>
not if he/she doesnt expect it
<KotCzarny>
;)
<KotCzarny>
board/uart plays dead
<MoeIcenowy>
for me I will connect a USB cable if the board doesn't respond me after rebooting
<megi>
I'm not too fond with connecting microUSB from Opi3 to my PC
<MoeIcenowy>
why
<megi>
VBUS/DCIN short
<KotCzarny>
as long you didnt set it to host mode beforehand, it should work?
<MoeIcenowy>
oh it's really shorted
<megi>
it doesn't have any switch there
<megi>
yes
<KotCzarny>
:)
<megi>
you can power it from PC though :D
<MoeIcenowy>
BTW my Pine H64 model B seems to be working at 1488MHz at 75 Celusis when two cores are 100%
<MoeIcenowy>
(running xz -T 2)
<MoeIcenowy>
maybe I should set the lowest trip point a little higher
<MoeIcenowy>
e.g. 85C?
<megi>
worth a try
<MoeIcenowy>
when 4 cores, temp is still 75C, but freq is 1008MHz
<MoeIcenowy>
but of course this board has no cooling additions
<megi>
I'd only worry, if there were electrolyte capacitors on the board
<MoeIcenowy>
tantalum ones dangerous?
<MoeIcenowy>
I don't think such a board will have electrolyte
<megi>
Orange Pi PC has
<MoeIcenowy>
H6 has even no tantalum capacitors
<MoeIcenowy>
all MLCC
<MoeIcenowy>
Pine H64 *
<megi>
good
<MoeIcenowy>
oh OPi PC really has an electrolyte C
<KotCzarny>
could it be that wdog doesnt have access to some parts of the system to execute reset?
<megi>
temperature will affect capacitance a bit on some ceramics, but if it works, it works.. I don't think it will affect the lifespan
<KotCzarny>
although it wouldnt work on other boards then
<MoeIcenowy>
BPi's usually have tantalum capacitor
<KotCzarny>
then yeah, something in hardware
<MoeIcenowy>
megi: Pine H64 is said to be a so compact board
<MoeIcenowy>
that the board designer is cutting doen functions to fit it
<MoeIcenowy>
I mean model B
<MoeIcenowy>
s/doen/down/
<MoeIcenowy>
the dedicated regulator for RTL8211E is dropped, and ALDO2 is used instead
<MoeIcenowy>
one LED is dropped (compare to early A sample)
<megi>
yeah, there are these differences also between various orange pi H6 boards
<megi>
some have xtra regulators for wifi some use AXP805
<megi>
one funny thing is that Orange Pi 3 has a led on the bottom
<megi>
not sure why
<megi>
perhaps for people running it upside down
<mru>
you got one of the boards meant for australia
<megi>
hahaha
<MoeIcenowy>
LED at down
<MoeIcenowy>
hahaha
<MoeIcenowy>
mru: what's this joke? I cannot understand it...
<megi>
it's a joke only if you live in europe
gamiee has quit [Ping timeout: 252 seconds]
<megi>
you're too close
<MoeIcenowy>
oh you mean that the australian people can see the LED blinking through the earth?
Nyuutwo has quit [Read error: Connection reset by peer]
<megi>
maybe if the led was on the side of the board you'd find it funny
<KotCzarny>
what about moon-people ?
<MoeIcenowy>
BTW is there anyone working on AXP803 vbus power driver?
Nyuutwo has joined #linux-sunxi
<MoeIcenowy>
(I mean the power input online status driver
<megi>
is that the same as in 813?
<MoeIcenowy>
megi: should be
<MoeIcenowy>
I now even doubt 803 is the same die w/ 813
<megi>
wasn't this part of the wens's recently merged patches?
<MoeIcenowy>
what?
<MoeIcenowy>
lemme check linux-next/master
<MoeIcenowy>
oh saw it
<MoeIcenowy>
"mfd: axp20x: Add USB power supply mfd cell to AXP813"
<megi>
yes
<MoeIcenowy>
megi: but the corresponding axp20x_usb_power patch is not seen...
<megi>
hmm
kaspter has quit [Read error: Connection reset by peer]
rexxster_ has quit [Ping timeout: 245 seconds]
kaspter has joined #linux-sunxi
<MoeIcenowy>
btw now I think it's really possible for AXP803 to be the same die with AXP813/818
<MoeIcenowy>
(of course, AXP81x has another AC100 die
<MoeIcenowy>
if we NC the FLDO3 and DCDC7 of AXP813, and connect DCDC1 to SWIN
<MoeIcenowy>
we get an AXP803
tllim has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
a|3x has joined #linux-sunxi
grosso has quit [Ping timeout: 255 seconds]
jaganteki has quit [Ping timeout: 256 seconds]
AneoX_ has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
shfil has joined #linux-sunxi
<curlybracket>
cch: VDD-EFUSEBP is for connecting a bypass capacitor. (A64 Olinuxino uses 10u)
<curlybracket>
*VDDBP-EFUSE
jstefanop has joined #linux-sunxi
<angelo_ts>
trying to enable i2s0 clock on H3
<angelo_ts>
getting this error : sun4i-i2s 1c22400.i2s: Can't get our mod clock
f0xx has quit []
f0xx has joined #linux-sunxi
netlynx has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<libv>
hrm, sysv ipc is missing from def conf
<libv>
which breaks fakeroot
<libv>
(sorry, mental note, /me goes back to preparing supper ;p)
<MoeIcenowy>
sysv ipc is deprecated ;-)
<libv>
fakeroot is still very much existent
<libv>
but i must remember to add this to the wiki
<karlp>
nah, just come bnack in a month and complain that it wasn't done, and that everyone must hate users....
<libv>
karlp: well done.
<karlp>
writing more pages doesn't grant you magic privilege to belittle people or demand special treatment you know.
<anarsoul>
karlp: wtf? why are you provoking a conflict?
<karlp>
you'd rather they get to come in here and tell people htey're all doign a shitty job?
cmeerw has joined #linux-sunxi
<libv>
heh
<libv>
karlp: thank you for contributing.
gamiee has joined #linux-sunxi
<MoeIcenowy>
anarsoul: do you have schedule to implement lima_blit?
<anarsoul>
MoeIcenowy: I haven't looked into it yet
<anarsoul>
go for it if you want to do it :)
<MoeIcenowy>
anarsoul: could I just use util_blitter?
<anarsoul>
sorry, no idea. As I said - I haven't looked into it yet
<MoeIcenowy>
anarsoul: how many features are supported now by lima?
reinforce has joined #linux-sunxi
BenG83 has quit [Ping timeout: 255 seconds]
rexxster has joined #linux-sunxi
clemens3 has quit [Ping timeout: 255 seconds]
DonkeyHotei has quit [Ping timeout: 246 seconds]
yann has quit [Ping timeout: 246 seconds]
afaerber has quit [Quit: Leaving]
cch has quit [Remote host closed the connection]
cch has joined #linux-sunxi
frozeus has joined #linux-sunxi
frozeus has quit [Client Quit]
frozeus has joined #linux-sunxi
frozeus has quit [Client Quit]
frozeus has joined #linux-sunxi
frozeus has quit [Client Quit]
clementp has joined #linux-sunxi
<clementp>
Hi
<clementp>
Can someone with an H64 board can test the watchdog timer ?
<clementp>
# devmem $((0x030090a0 + 0x0014)) => should return 0x00000001
<clementp>
# devmem $((0x030090a0 + 0x0018)) => should return 0x0
<clementp>
# devmem $((0x030090a0 + 0x0018)) 32 0x1 => should made the board reboot or stuck
<anarsoul>
MoeIcenowy: well, if you have a list of specific features - I probably can answer
<anarsoul>
MoeIcenowy: lima_blit is missing as you already noticed
<anarsoul>
also there's no control flow support for now (but we have bcsel - so simple ifs will work)
cperon[m] has joined #linux-sunxi
<anarsoul>
I recently added support for depth/stencil fbo attachments (not merged yet)
<anarsoul>
cubemap support is missing (but shouldn't be hard to add)
<anarsoul>
gp compiler lacks support for exp2 and log2
vagrantc has joined #linux-sunxi
vagrantc has quit [Changing host]
vagrantc has joined #linux-sunxi
cch__ has joined #linux-sunxi
cch has quit [Ping timeout: 240 seconds]
cch__ is now known as cch
tnovotny has quit [Quit: Leaving]
<MoeIcenowy>
clementp: Rongpin RP-H6B seems to be okay
<MoeIcenowy>
anarsoul: BTW GNOME performs very bad on current lima
<MoeIcenowy>
but it at least runs
<anarsoul>
MoeIcenowy: I wouldn't expect gnome to work
<anarsoul>
anyway, you can check the logs to see what's going wrong
<cperon[m]>
hmmm, ok with the cmd reboot or the wdt ? The reboot should works if the BL31 is from the vendor releaseas they used the ARISC and not the WDT.
Nakaori has quit [Ping timeout: 250 seconds]
<cperon[m]>
Or maybe there is a different rev hardware.
clementp has quit [Quit: Page closed]
cperon[m] is now known as clementp[m]
<MoeIcenowy>
by the way
<MoeIcenowy>
the string on the chips of all Pine H64's and RP-H6B is "V200 AWIN"
<MoeIcenowy>
clementp[m]: what's your board's H6 chip "variant string"?
<megi>
on Opi3 it's V200-AI
<MoeIcenowy>
maybe this is difference?
<megi>
maybe
<clementp[m]>
The HW marking on my SoC is "V200 AWIN H7309BA 6842"
<megi>
no the other one
<megi>
ah
<clementp[m]>
Beelink GS1 and the WDT is not functionnal
<megi>
so that's not it :)
clemens3 has joined #linux-sunxi
<clementp[m]>
I'm also trying to make the IR functionnal on H6 but nothings seems to append and FIFO stay empty at low-level
<MoeIcenowy>
anarsoul: is your implementation okay?
<anarsoul>
MoeIcenowy: conditionals are in the works, rellla is working on them, IIRC it needs gl_FragCoord
<clementp[m]>
maybe you're looking the A64 patch not the H6 one
<anarsoul>
MoeIcenowy: you mean for sin/cos?
<MoeIcenowy>
sincos
<MoeIcenowy>
yes
<anarsoul>
well, lowering pass is OK, but GP compiler can't handled produced IR
<MoeIcenowy>
oh what
<anarsoul>
:)
<anarsoul>
MoeIcenowy: GP in mali4x0 doesn't have instructions for sin/cos
<MoeIcenowy>
is sin/cos required for gles2?
<anarsoul>
so sin/cos must be lowered to polynomial
<megi>
clementp[m]: you're right
<anarsoul>
MoeIcenowy: yes
<MoeIcenowy>
so the blob also do such lowering?
<anarsoul>
yes
Andy-D has joined #linux-sunxi
<anarsoul>
basically it turns sin(x) into x - (x^3 / 3!) + (x ^ 5 / 5!) + ...
<MoeIcenowy>
implemented a simple blit process
<anarsoul>
IIRC blit was necessary for refract demo
<MoeIcenowy>
so I should try it now?
<anarsoul>
yeah, why not
<MoeIcenowy>
Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cdd)\nError: Failed to set up the render target for the depth pass
Nakaori has quit [Remote host closed the connection]
<anarsoul>
yeah, something's not right
<MoeIcenowy>
seems that GNOME Shell itself barely works
<MoeIcenowy>
but GTK+ programs get quite messed up
<MoeIcenowy>
maybe glamor has issue
Nakaori has joined #linux-sunxi
<anarsoul>
it makes sense to start running tests, dEQP or piglit
shfil has quit [Quit: Connection closed for inactivity]
<libv>
so more modern sunxi really have no blitter anymore, and it has not magically turned up along the way again either?
<libv>
blitters are such trivial engines and they can do such a useful job, just like overlays
<libv>
x86 graphics hw had dropped these engines in the 2005-2010 timeframe, and so did imagination with powervr
<MoeIcenowy>
libv: yes
<libv>
and then when i, as part of nokia, saw the introduction of the rogue, they had added a blitter back
<MoeIcenowy>
only R40 have one
<libv>
because that's just a quad core a20
<libv>
i will end up using g2d for fosdem
<libv>
to do a blit with colour space conversion from the camera interface to the h264 encoder
<libv>
with little state to be set up
<MoeIcenowy>
maybe I should check glamor source
<libv>
we used pvr2d for the nokia n9
<MoeIcenowy>
to find out why lima now doesn't work for it
<libv>
on the sgx
<libv>
and some tests were just horrific
<libv>
until we moved small blits to the cpu instead of using the powervr
<anarsoul>
MoeIcenowy: most likely it cannot digest some glamor shader
<libv>
a 3d engine eats power, and needs huge amounts of state
<MoeIcenowy>
anarsoul: how to enable debug out of lima?
<anarsoul>
MoeIcenowy: LIMA_DEBUG=all
<anarsoul>
just set this env
<anarsoul>
if you want to debug gp or pp individually you can use LIMA_DEBUG=gp or LIMA_DEBUG=pp
<anarsoul>
libv: well, with 1080p it's more efficient to use gpu for blitting than doing blits on CPU
<anarsoul>
libv: also for modern GUI blitter is pretty much useless
<libv>
for the first, yes
<libv>
the second, no
<libv>
it's just not implemented because in the 2005-2010 timeframe the mantra was that both for blitters and for overlays, it could all be done in the 3d engine anyway
<libv>
but there was a reason why drm planes were added, and the reason was that wayland was horribly slow and heavy compared to android hw_composer
<libv>
but the first pass at drm planes was done by jesse at intel, and intel had just moved to sandy bridge, where, following te mantra of the second half of the naughties, the number of overlays per crtc was reduced to 1 (not counting the cursor)
<libv>
which is why z-ordering of "planes" was not part of the first implementation
<anarsoul>
but overlays aren't blitters
<MoeIcenowy>
anarsoul: LIMA_DEBUG dumps nothing
<libv>
i am quite aware of that
<MoeIcenowy>
is other things needed?
<anarsoul>
MoeIcenowy: you need to use debug build of mesa
<libv>
but they fell prey to the exact same thinking that everything could be done on the 3d engine
<MoeIcenowy>
how to make a build debug?
<anarsoul>
do you use meson?
<MoeIcenowy>
--enable-debug?
<MoeIcenowy>
no I use autotools
<anarsoul>
I think it's --enable-debug for autotools
<anarsoul>
but note that autotools are being abandoned in upstream mesa
<MoeIcenowy>
when?
<MoeIcenowy>
anarsoul: how does meson do cross compile?
<anarsoul>
no idea, I do native builds. But there should be a way
<megi>
MoeIcenowy: you need a cross file
<MoeIcenowy>
cross file
<MoeIcenowy>
weird
<anarsoul>
MoeIcenowy: well, meson is faster at least for native builds