00:08
lurchi__ is now known as lurchi_
00:12
RichardG867 has quit [Quit: Keyboard not found, press F1 to continue]
00:14
RichardG867 has joined #linux-sunxi
00:23
dev1990 has quit [Quit: Konversation terminated!]
00:25
tllim has quit [Quit: Leaving]
01:02
jbrown has quit [Ping timeout: 258 seconds]
01:02
victhor has quit [Ping timeout: 264 seconds]
01:04
megi has quit [Ping timeout: 250 seconds]
01:11
vagrantc_ has quit [Quit: leaving]
01:25
Rafael1980 has quit [Quit: Konversation terminated!]
01:29
xes has quit [Ping timeout: 255 seconds]
01:31
xes has joined #linux-sunxi
01:49
AneoX_ has quit [Read error: Connection reset by peer]
01:49
AneoX has joined #linux-sunxi
01:55
dddddd has quit [Remote host closed the connection]
02:03
lurchi_ is now known as lurchi__
02:18
lurchi__ is now known as lurchi_
02:19
agraf has quit [Ping timeout: 246 seconds]
02:23
agraf has joined #linux-sunxi
02:26
Gerwin_J has quit [Quit: Gerwin_J]
02:35
sunshavi has quit [Ping timeout: 250 seconds]
02:35
DonkeyHotei has quit [Read error: Connection reset by peer]
02:36
DonkeyHotei has joined #linux-sunxi
02:40
Andy-D has quit [Ping timeout: 255 seconds]
02:44
shfil has quit [Quit: Connection closed for inactivity]
02:45
sunshavi has joined #linux-sunxi
02:54
lurchi_ is now known as lurchi__
03:27
leviathanch has joined #linux-sunxi
03:50
camus has joined #linux-sunxi
03:51
kaspter has quit [Ping timeout: 240 seconds]
03:51
camus is now known as kaspter
04:16
TheSeven has quit [Disconnected by services]
04:16
[7] has joined #linux-sunxi
04:25
ganbold has joined #linux-sunxi
04:44
vagrantc_ has joined #linux-sunxi
05:06
f0xx has joined #linux-sunxi
05:24
return0e_ has joined #linux-sunxi
05:25
return0e has quit [Ping timeout: 255 seconds]
05:26
lurchi_ has joined #linux-sunxi
05:27
vagrantc_ has quit [Quit: leaving]
05:30
lurchi__ has quit [Ping timeout: 255 seconds]
05:35
[7] has quit [Ping timeout: 250 seconds]
05:35
TheSeven has joined #linux-sunxi
06:00
<
plaes >
vagrantc: does it use some gpio to turn on regulator?
06:09
ganbold has quit [Quit: This computer has gone to sleep]
06:21
IgorPec has joined #linux-sunxi
06:23
selfbg has joined #linux-sunxi
06:43
nuuuciano_ has quit [Ping timeout: 244 seconds]
07:13
fl_0 has quit [Ping timeout: 250 seconds]
07:14
paulk-leonov has quit [Ping timeout: 258 seconds]
07:14
paulk-leonov has joined #linux-sunxi
07:18
fl_0 has joined #linux-sunxi
07:23
reinforce has joined #linux-sunxi
07:41
<
vagrantc >
plaes: possibly...
07:53
leviathanch has quit [Remote host closed the connection]
07:54
angelo_ts has joined #linux-sunxi
07:58
<
angelo_ts >
hi all, totally new to allwinner, so have some basic questions if someone have time :) . Where does "sunxi" term comes from ? I am lookign around for H3 updated kernel, mainline seems not updated, and sunxi wiki seemms to be for tha A serie. Where could i find updated stuff for the H3 ?
08:04
<
vagrantc >
most recent stuff gets most active development on mainline...
08:05
<
gnarface >
angelo_ts: manufacturer's product name i think
08:05
<
gnarface >
angelo_ts: not of the H3 necessarily, but of whatever thing the original linux kernel driver was made for
08:08
DonkeyHotei has quit [Read error: Connection reset by peer]
08:09
DonkeyHotei has joined #linux-sunxi
08:16
<
rellla >
oh, to complete it: sunxi is a summary term for all the sun4i, sun5i ..., where "x" stands for the number.
08:19
msimpson has joined #linux-sunxi
08:21
<
angelo_ts >
thanks all, really kind
08:22
<
angelo_ts >
rellla, i mean in my linux.git/drivers/net/ethernet/allwinner (pulled some days ago, i am in 5.0.x kernel) i cannot see a sun8i-emac.c
08:25
airwind has joined #linux-sunxi
08:25
clemens3_ has joined #linux-sunxi
08:32
<
angelo_ts >
rellla, uhm very interesting
08:36
<
angelo_ts >
my 4.10 kernel here uses a sun8i-emac.c driver quite different, probably older initial stuff ? Btw, backpoprting changes to 4.10 seems a problem right now.
08:36
<
angelo_ts >
this, to stuck in a specific klernel version, are comany chioces, thanks btw
08:38
<
angelo_ts >
ok and i found the story
08:38
<
angelo_ts >
now all is clear
08:49
vagrantc has quit [Quit: leaving]
09:03
tnovotny has joined #linux-sunxi
09:12
Gerwin_J has joined #linux-sunxi
09:17
megi has joined #linux-sunxi
09:28
leviathanch has joined #linux-sunxi
09:38
victhor has joined #linux-sunxi
09:41
Gerwin_J has quit [Quit: Gerwin_J]
09:57
dddddd has joined #linux-sunxi
09:57
fkluknav has quit [Remote host closed the connection]
09:59
fkluknav has joined #linux-sunxi
10:04
<
mru >
4.10? what is wrong with people?
10:12
ganbold has joined #linux-sunxi
10:13
<
KotCzarny >
isnt bsp 4.4 ?
10:13
<
mru >
the TLA of doom
10:14
<
mru >
over here we're running 4.19
10:22
IgorPec has quit [Ping timeout: 268 seconds]
10:26
victhor has quit [Ping timeout: 257 seconds]
10:33
Gerwin_J has joined #linux-sunxi
10:45
shfil has joined #linux-sunxi
11:24
aep has joined #linux-sunxi
11:24
<
aep >
can i enable gpios when they're missing from the dtb?
11:25
<
aep >
specifically sun8i-h2-plus-orangepi-zero.dts doesn't define any gpios, so i cant figure out the numbers
11:26
<
fALSO >
libgpiod doesnt work ?
11:26
<
fALSO >
i've used it with a h3
11:26
<
fALSO >
blinked some leds :-P
11:27
<
aep >
well i can export pins with /sys/class/gpio, but i dont know which ones
11:27
<
aep >
since i can't find the mapping in the dts
11:27
<
aep >
and the ones i found googling dont work
11:27
<
fALSO >
its probably on a h2 "generic" file
11:27
<
fALSO >
check if your dts doesnt include another ones
11:28
<
aep >
nothing in the resulting dtb tho
11:28
<
fALSO >
probably one about gpio
11:28
<
mru >
what is it you can't find?
11:29
<
aep >
well, no idea what i'm looking for. i guess some mappings from the sunxi pin names to linux?
11:30
<
mru >
PA0-31 => gpio0-31
11:30
<
mru >
PB0-31 => gpio32-63
11:30
airwind has quit [Quit: airwind]
11:30
<
aep >
oh its standard?
11:30
<
mru >
32 pins per bank
11:30
<
mru >
though not all of them exist on all chips
11:31
<
aep >
but pin 0-16 do nothing
11:32
<
aep >
i mean gpio 0-16
11:32
<
aep >
hence i thought they might still need to be configured
11:32
<
aep >
like, where's the pull-up config for example
11:32
<
mru >
which pins are you trying to use?
11:32
<
aep >
any, but lets say Pa06
11:32
<
aep >
that would be gpio6, but that doesnt have any effect
11:33
Gerwin_J has quit [Quit: Gerwin_J]
11:34
<
aep >
huh, works as out direction. just not in
11:36
<
aep >
ok dunno, probably electrical rather than software then
11:36
<
aep >
do they have pull-ups that can be configured?
11:39
<
aep >
not sure if you can mix dts and fex
11:40
<
mru >
you can enable pull-ups in dts, yes
11:41
<
aep >
KotCzarny: yeah, no help for dts there
11:41
<
aep >
mostly mentiones fex
11:41
<
mru >
you don't want fex
11:42
<
aep >
going to figure out how to add an overlay :)
11:43
<
KotCzarny >
but allows you to fool around the gpios
11:43
<
KotCzarny >
even without dts i think
11:43
<
aep >
can you mix it with dts?
11:44
<
KotCzarny >
you have to know which pins are of interest to you though
11:44
<
aep >
that would be convenient
11:44
<
KotCzarny >
which is what dts is for
11:44
<
KotCzarny >
device one
11:48
<
mru >
seems like libgpiod is going to get support for setting pullup/pulldown, but it will require kernel changes to expose those settings to userspace
11:49
<
mru >
so for now you'll need to configure that in dts
11:55
<
pgreco >
somewhat related question, I'm currently using bpi-m1 which has 3 uarts exposed by default
11:56
<
pgreco >
I'm thinking about changing to bpi-m2u, which only has 1 enabled in dtb
11:56
<
pgreco >
is there any way to enable those in runtime? or just fdtput and reboot?
12:02
IgorPec has joined #linux-sunxi
12:13
kaspter has quit [Ping timeout: 255 seconds]
12:14
Rafael1980 has joined #linux-sunxi
12:15
jbrown has joined #linux-sunxi
12:19
<
aep >
cant figure out how the dts works :/
12:19
<
aep >
this has no effect
12:26
<
fALSO >
wasnt it a h2 ?
12:29
<
aep >
good point. i dunno why there's a h3 in there
12:29
<
aep >
this is the stock dtc
12:29
<
KotCzarny >
because h2+ is basically h3
12:29
<
KotCzarny >
with few capabilities cut
12:32
<
MoeIcenowy >
KotCzarny: with nothing cut
12:32
<
MoeIcenowy >
except with stock software by AW
12:32
<
KotCzarny >
MoeIcenowy: lol?
12:32
<
KotCzarny >
but arent those cut because silicon got bad or something?
12:32
<
MoeIcenowy >
they're just some H3 chosen that have not so good power
12:32
<
MoeIcenowy >
KotCzarny: it's only marketing
12:33
<
KotCzarny >
but do they work in the missing areas just fine or experience problems?
12:33
<
MoeIcenowy >
just fine
12:33
<
KotCzarny >
interesting.
12:33
<
MoeIcenowy >
in fact some of them are only "spec cut"
12:33
<
MoeIcenowy >
even no code cut is executed
12:33
<
MoeIcenowy >
e.g. GbE
12:34
<
MoeIcenowy >
Banana Pi verified GbE on H2+ with BSP kernel
12:34
<
KotCzarny >
so if i change code paths in kernel that detect h2+ as h3 it will work as plain h3?
12:34
<
MoeIcenowy >
there's somewhere that checks the SID
12:34
<
mru >
sounds like standard chip binning
12:34
<
KotCzarny >
gonna try that sometime
12:34
<
mru >
everybody does that
12:34
<
KotCzarny >
i still would suspect the silicon throwing errors sometimes
12:34
<
MoeIcenowy >
H6 is another story
12:35
<
MoeIcenowy >
it has hidden binning
12:35
<
MoeIcenowy >
all speed bins are sold mixedly
12:35
<
MoeIcenowy >
but the worst speed bin will work on higher voltage
12:35
<
MoeIcenowy >
thus make more heat
12:35
<
MoeIcenowy >
when with BSP
12:35
kaspter has joined #linux-sunxi
12:36
<
MoeIcenowy >
and as mainline have no bin reading code
12:36
<
MoeIcenowy >
it now blindly use the DVFS table of the worst bin
12:36
<
KotCzarny >
how cute
12:37
<
megi >
so it's a lottery
12:37
<
mru >
wouldn't it be great if vendors worked to get things upstream rather than actively sabotaging it?
12:37
<
KotCzarny >
i wonder if they sell them randomly too
12:37
<
KotCzarny >
or have some price tiers
12:38
<
aep >
hmm actually none of the peripherals are enabled. i wonder if the default dts is just broken.
12:38
<
aep >
or is the compatible = "allwinner,sun8i-h3-pinctrl"; actually wrong?
12:38
<
MoeIcenowy >
megi: yes, lotttery
12:38
<
MoeIcenowy >
my different revison Pine H64 have different bin
12:38
<
megi >
MoeIcenowy: how do you read the bin?
12:38
<
mru >
then you might as well assume worst case and go with it
12:39
<
MoeIcenowy >
megi: refer to BSP SID code
12:39
<
KotCzarny >
that's what she wrote
12:39
<
megi >
MoeIcenowy: will look, thanks
12:39
<
KotCzarny >
(the worst case in mainline)
12:39
<
MoeIcenowy >
I have no H6 SDK on hand
12:39
<
mru >
since your product has to work whichever chip you got
12:39
<
megi >
I wonder what I have won with Opi 3 :)
12:39
<
MoeIcenowy >
because my HDD broken on last Nov
12:39
<
MoeIcenowy >
and since then I have no need for BSP
12:39
<
MoeIcenowy >
thus I didn't redownload it ;-)
12:39
<
MoeIcenowy >
I now only have A64 4.9 BSP on hand
12:40
<
MoeIcenowy >
megi: see drivers/soc/sunxi/sunxi-sid.c in BSP 4.9
12:40
<
megi >
MoeIcenowy: found the bin registers
12:41
<
plaes >
does this exist on A20 too?
12:42
<
plaes >
any idea what does this bin number mean? 1 is better, 3 worst?
12:42
<
megi >
aparently, there are 3 bins
12:43
<
plaes >
0: fail, 1: slow, 2: normal, 3: fast
12:44
<
KotCzarny >
fails for all
12:44
<
megi >
it's used only by the sunxi-cpufreq.c driver
12:47
<
megi >
looks like there's also something named psensor_bin, accessed directly via a sunxi-cpufreq.c driver
12:48
<
megi >
fail is normal, for aw apparently
12:48
<
megi >
perhaps it's just "fail to read the sid", though
12:49
<
megi >
now, it finally makes sense why there are multiple dvfs tables in the fex file
13:08
akaWolf has joined #linux-sunxi
13:08
<
aep >
so i just tried the official image from orange pi and its missing i2c as well. i guess upstream dts is just a copy of the official one
13:08
<
aep >
which doesnt work D:
13:09
<
aep >
is there any other h2+ board with i2c that i could copy the dts from?
13:10
<
megi >
&i2c1 { status = "okay"; } and updating aliases doesn't work?
13:10
<
aep >
uh let me try
13:10
<
megi >
I just edit the in-kernel dts and recompile, when enabling these interfaces
13:11
<
aep >
yeah, i'm using dts to do the same
13:12
<
aep >
dtc dtb > source ; edit source ; dtc source > dtb
13:12
<
megi >
okay, so you should probably edit the status property of the i2c node instead
13:13
<
aep >
doesnt have one by default
13:13
<
aep >
status = "disabled";
13:13
<
megi >
that means it's enabled
13:13
<
aep >
i was looking in the wrong place
13:14
<
megi >
pinctrl I guess?
13:14
<
megi >
it's named similarly
13:15
<
aep >
btw any idea why i cant get pinctrl to change pull-up?
13:15
<
aep >
i added the uuser thing
13:16
<
megi >
it's just a definition
13:16
<
mru >
nothing uses it
13:16
<
megi >
you need to use it somewhere
13:17
<
aep >
is there a dummy use thing or something?
13:17
<
aep >
not sure what would use it
13:17
<
megi >
you can add it to anything that's enabled
13:18
<
megi >
or look through Documentation/devicetree/bindings
13:20
<
aep >
i think i need a primer on the syntax :/
13:21
<
aep >
there isnt really any documentation what "definition" vs use actually is
13:21
<
megi >
look at pinctrl-0 properties
13:22
<
megi >
you may have easier time editing dts that are in the kernel tree, rather than what's decompiled by dtc
13:22
<
aep >
yeah these are refs i guess. but i can just slap mine on any other node? i thought that would break something else
13:22
<
megi >
editing and understanding
13:23
<
megi >
it's a hack of course :)
13:23
nuuuciano_ has joined #linux-sunxi
13:23
<
aep >
like if i add my new pin to i2c@01c2ac00 { pinctrl-0 wont that change how i2c works?
13:23
<
megi >
you can add your def there pinctrl-0 = <&uart_pins &your_pins>
13:23
<
aep >
i'll give it a shot. see what happens :D
13:23
<
megi >
and when uart is probed, it will configure both sets of piis
13:24
<
aep >
yeah i was worried they'll both be uart then
13:24
<
megi >
nothing will break for the uart
13:24
<
megi >
they'll be configured to what's defined by the nodes under the pinctrl
13:25
<
aep >
oh that makes sense
13:26
<
megi >
you can probably place a pinctrl-0 property for your pins in a more sensible place - perhaps under pinctrl node itself, but I'm not sure if it would not create a loop
13:26
penpatde has quit [Quit: bbl]
13:27
<
aep >
i'm going to try your hack. thanks so much
13:29
<
mru >
for pins that need configuring but don't belong to another device, it's usual to reference the config node from the pinctrl device itself
13:29
<
megi >
mru: good to know
13:29
<
aep >
megi: with pinctrl-0 as well?
13:30
<
megi >
looks like it, I never tried
13:32
fkluknav has quit [Remote host closed the connection]
13:32
fkluknav has joined #linux-sunxi
13:36
<
aep >
well that broke it. but i might have messed up the phandle thing
13:36
<
aep >
going to edit the source instead...
13:37
<
aep >
good news is just the i2c change works. :)
13:38
<
megi >
btw it looked like you have double quotes in your user@1 pin config
13:38
<
megi >
around pin name
13:38
<
mru >
double double even
13:40
<
mru >
toil and trouble
13:40
<
mru >
fire burn and cauldron bubble
13:41
<
megi >
double double...
13:41
reinforce has quit [Ping timeout: 245 seconds]
13:41
<
megi >
I had to google it though :)
13:42
reinforce has joined #linux-sunxi
13:43
<
aep >
i had to get the hint to google it :P
13:45
<
mru >
do people not read shakespeare any more?
13:46
<
MoeIcenowy >
megi: I think there's code that control the usage of DVFS table according to speed bin
13:49
<
aep >
mru: outside of the UK? probably not :P
13:51
<
mru >
where are you guys?
13:51
<
megi >
MoeIcenowy: it's in sunxi-cpufreq.c
13:52
<
aep >
mru: .de ; could you give me a hint where the reference from pinctrl itself thing is documented?
13:52
<
megi >
mru: we were thought some Shakespeare, but not in English
13:52
<
aep >
i'm not sure if pinctrl-0 = &mything is correct
13:52
<
megi >
+ pinctrl-names = "default"
13:53
<
aep >
hm ok. let me try
13:53
<
mru >
aep: see the link I posted a while ago
13:53
<
aep >
yeah i tried reading it, i couldnt figure that part out
13:55
aalm has quit [Ping timeout: 250 seconds]
13:55
<
fALSO >
Someone knows the admin of the WIKI ?
13:56
<
fALSO >
Plz report that it isnt sending mails to confirm new users
13:57
<
megi >
it might be rellla?
13:58
<
rellla >
i don't have server access. ^^ libv?
13:59
<
fALSO >
i wanted to edit the orange pi one plus page
13:59
<
fALSO >
and i have a patch to submit to the mailinglist
13:59
<
fALSO >
adding ethernet support
13:59
<
fALSO >
but im afraid of posting it ;-)
14:00
<
fALSO >
if anyone wants to post for me
14:00
<
mru >
it'll still have your name on it
14:00
<
libv >
mnemoc, Turl_: ^^^ email issues
14:00
<
mru >
don't worry, the sunxi maintainers are friendly
14:02
<
fALSO >
you can put it in your name :-P
14:02
<
fALSO >
im afraid of posting it and doing something wrong
14:03
<
fALSO >
and then.... i cant delete the submission from the internets
14:03
<
fALSO >
:-PPPPPPPPPPPPPPPPPPPP
14:03
lurchi_ is now known as lurchi__
14:04
<
fALSO >
i hacked and slashed that patch from some armbian ones for 4.20
14:04
<
fALSO >
and i asked permission of armbian to submit it
14:04
<
aep >
fALSO: come on, just post it
14:04
<
fALSO >
got to learn git-email
14:04
<
aep >
yeah that part sucks
14:04
<
fALSO >
and configure it with a gmail account
14:05
<
aep >
but its satisfying AF to get something into mainline ;)
14:05
<
mru >
at least the first few times
14:05
<
aep >
yeah just dont become a maintainer
14:06
<
mru >
I'm "maintainer" of some obscure stuff nobody cares about
14:06
<
mru >
I get my name in the file without any of the burdens
14:06
<
fALSO >
i just like to buy unsupported boards
14:06
<
fALSO >
and try to get them somewhat working
14:07
<
megi >
fALSO: I'm jealous of eth working for you on Orange Pi One Plus, on Orange Pi 3 it's messed up
14:07
<
fALSO >
you can try my patch
14:07
<
fALSO >
on the dts of the orange pi 3
14:07
<
fALSO >
it will probably work
14:07
<
fALSO >
is it a h6 too ?
14:07
<
megi >
I already did, the hw is different though
14:10
<
montjoie >
hello what I need to add emac in H6 uboot, does copying DT is sufficient ?
14:12
<
megi >
Orange Pi 3 is annoying in one other aspect... they used AP6256, which compared to AP6255 doesn't have mainline support
14:12
<
mru >
is that some horrid wifi/bt module?
14:13
<
megi >
I still hope it just has a different bluetooth part, and WiFi part will work with the driver for AP6255
14:13
<
mru >
the kernel drivers usually work once you find the right firmware and figure out which quirk flags to set
14:13
<
megi >
if you look at the firmware for AP6256, it has string references to AP6255
14:14
<
megi >
mru: AP6256 is supported by the out of tree driver for some old kernel
14:20
IgorPec has quit [Ping timeout: 245 seconds]
14:24
<
MoeIcenowy >
maybe I should consider to purchase an Orange Pi 3
14:24
<
MoeIcenowy >
although for H6 board I still prefer Pine H64
14:25
<
megi >
MoeIcenowy: I like 4 USB3 ports, my plan is to have USB3/gigabit ethernet dongles there and use it as a 5 port router
14:25
<
KotCzarny >
MoeIcenowy: ask xunlong to send you few boards?
14:25
<
montjoie >
copying dt seems to block uboot for pineH64
14:25
<
montjoie >
KotCzarny: xunlong at least always ignored me for samples
14:26
* mru
would not use usb ethernet for a router
14:26
<
montjoie >
perhaps I should retry asking as kernelci
14:26
Andy-D has joined #linux-sunxi
14:27
BenG83 has joined #linux-sunxi
14:30
<
megi >
mru: I'll have to try before deciding if it will be a mistake or not :)
14:31
<
mru >
usb is usually a mistake
14:34
<
megi >
I just want to route perhaps 3 ports, it would be quite surprising if 4 core a53 at 1.5GHz would fail at that
14:35
<
megi >
even with usb
14:35
<
mru >
the cpu isn't the issue
14:35
<
mru >
the general nastiness of usb is
14:35
<
mru >
and the typically crap quality of usb devices
14:36
<
megi >
yeah, I have som 100Mbit dongles, that are losing the link frequently for seemingly no reason
14:37
<
megi >
though the gigabit one I've sampled seems to be ok so far
14:37
tnovotny has quit [Quit: Leaving]
14:37
<
mru >
usb ethernet dongles are useful in a pinch, but I wouldn't want to rely on them
14:38
GrimKriegor has joined #linux-sunxi
14:38
GrimKriegor has quit [Changing host]
14:38
GrimKriegor has joined #linux-sunxi
14:53
<
montjoie >
oh in fact, it seems that master branch uboot, breaks h6
14:53
zoums has quit [Ping timeout: 268 seconds]
14:53
zoums has joined #linux-sunxi
14:57
aalm has joined #linux-sunxi
14:58
IgorPec has joined #linux-sunxi
14:59
selfbg has quit [Remote host closed the connection]
15:00
zoums has quit [Ping timeout: 246 seconds]
15:00
zoums has joined #linux-sunxi
15:03
<
KotCzarny >
montjoie: that's sad, but i guess it's about getting introduced properly doing the trick
15:04
<
aep >
finally got a sunxi kernel compiled.
15:04
<
aep >
megi: this isnt right :/
15:09
<
montjoie >
anone with pineh64 blocked with "Trying to boot from MMC1"
15:13
<
mru >
is mmc1 what it normally boots from?
15:13
<
mru >
and did you mess with u-boot?
15:13
<
mru >
that message is from u-boot spl, before it loads the main u-boot
15:13
<
montjoie >
at least I have log of an old boot which works after that
15:14
<
fALSO >
montjoie, are you using sunxi-next?
15:14
<
fALSO >
i think theres a lot of patches from moeicenowy for pineh64 there
15:14
<
fALSO >
check if moeicenowy doesnt have a uboot fork with patches for that too
15:15
<
montjoie >
fALSO: uboot sunxi-next ?
15:15
<
fALSO >
sunxi next i meant the kernel
15:15
<
fALSO >
but your problem seems to be on uboot
15:15
<
montjoie >
fALSO: yes it is pure uboot
15:16
<
fALSO >
it boots my orange pi one plus
15:16
<
fALSO >
just doesnt give any output
15:16
<
fALSO >
just via serial
15:16
<
montjoie >
and I try also 2019.01-rc3
15:16
<
montjoie >
fALSO: I use a serial
15:16
<
fALSO >
are you building atf too ?
15:17
<
fALSO >
from that is seems is supported montjoie
15:17
<
fALSO >
ahh thats pine64
15:17
<
fALSO >
your is pineH64
15:17
<
montjoie >
fALSO: pineH64
15:18
<
fALSO >
it mentions PineH64
15:18
<
fALSO >
so i guess it should work
15:18
<
fALSO >
are you building ATF too ?
15:20
<
montjoie >
I have builded ATF, but an old one
15:20
<
montjoie >
but it worked with the beta PineH64
15:21
<
fALSO >
i have some instrutions for the orange pi one plus
15:21
<
fALSO >
but its in portuguese.... in my personal wiki
15:21
<
fALSO >
i think you can follow the boot.scr changing the dtb file there...
15:21
<
fALSO >
and then building the ATF
15:22
<
fALSO >
and then uboot, just changing the config name
15:22
<
fALSO >
i know its not the same, just trying to help you out
15:22
jbrown has quit [Ping timeout: 258 seconds]
15:22
<
fALSO >
i have pages like these one for all my boards
15:22
<
megi >
aep: try making the the uart node a user of your pin config
15:22
<
fALSO >
with instrutions on how to "build" a distribution ;-)
15:23
<
fALSO >
mainly gentoo or arch ehehe
15:23
<
megi >
aep: just as an experiment
15:26
<
megi >
aep: you can specify multiple definitions as pinctrl-0 = <&pindef1>, <&pindef2>;
15:30
<
megi >
fALSO: nice logo
15:32
<
fALSO >
in portuguese wiki peida
15:32
<
fALSO >
peida -> ass
15:32
<
fALSO >
lololololol
15:32
<
megi >
ah, makes way more sense :)
15:32
<
fALSO >
its a fun with words
15:32
<
fALSO >
a friend of mine did the logo =)
15:33
<
fALSO >
i mainly use it
15:39
<
aep >
megi: yeah no chance
15:39
<
aep >
that does nothing
15:39
<
aep >
i.e. doesnt configure the pin
15:42
<
montjoie >
fALSO: updating ATF made it works!
15:44
<
megi >
aep: doesn't it need also function = "gpio_in" or something like that?
15:44
<
fALSO >
=))))))))))
15:44
<
aep >
yeah did that too
15:45
<
megi >
aep: hmm, I'm out of ideas
15:45
<
aep >
yeah. i'm soldering on a pull up :(
15:46
<
fALSO >
montjoie, fixe
15:46
<
fALSO >
i wrote in portuguese LOL
15:47
reinforce has quit [Quit: Leaving.]
15:52
IgorPec has quit [Ping timeout: 255 seconds]
15:53
<
montjoie >
note that sun8i_emac fail to compile with h6 on uboot
15:53
<
fALSO >
hum it worked for me
15:53
<
fALSO >
i got ethernet and fixed mac address working on the orange pi one plus
15:54
<
montjoie >
fALSO: but in kernel, in uboot there are no support for it
15:55
<
fALSO >
that i dont know
15:55
<
fALSO >
you want to boot from network on uboot ?
15:56
<
fALSO >
ahh, i never did that montjoie ;-(
15:56
<
montjoie >
it is needed for LAVA/kernelci
16:03
msimpson has quit [Quit: Leaving]
16:04
fkluknav has quit [Remote host closed the connection]
16:05
fkluknav has joined #linux-sunxi
16:12
kaspter has quit [Read error: Connection reset by peer]
16:13
kaspter has joined #linux-sunxi
16:14
tllim has joined #linux-sunxi
16:15
arc_phasor has joined #linux-sunxi
16:15
<
arc_phasor >
lol woops
16:15
<
arc_phasor >
i'm confused as to how to determine the GPIO in the device tree.
16:15
<
arc_phasor >
gpio = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
16:16
<
arc_phasor >
how is that equal to PB07, and what is the difference between pio and r_pio?
16:16
<
KotCzarny >
did you see wiki's page on gpio?
16:16
<
KotCzarny >
A=0, B=1, C=2, etc
16:17
<
arc_phasor >
oh ok, i don't see that
16:18
<
arc_phasor >
makes sense though, thanks!
16:18
<
arc_phasor >
is there a difference between pio and r_pio?
16:18
ec0 has quit [Ping timeout: 250 seconds]
16:19
ec0 has joined #linux-sunxi
16:20
<
arc_phasor >
KotCzarny: does r_pio start out 0 = L?
16:21
<
KotCzarny >
r_pio is for arisc access to the gpio
16:21
<
arc_phasor >
no idea what that means
16:22
<
KotCzarny >
ignore r_pio then
16:22
<
KotCzarny >
and the rules are the same
16:22
<
arc_phasor >
welp, i'll try to find some info on it, is it linux-sunxi specific?
16:23
t3st3r has joined #linux-sunxi
16:23
<
arc_phasor >
KotCzarny: I've read that.
16:23
<
KotCzarny >
there was a better page on gpio
16:24
<
fALSO >
it just works
16:24
<
fALSO >
someone here told me about a system path
16:24
<
fALSO >
that holds that board NAMES <-> GPIO pin
16:24
<
fALSO >
a file with that
16:24
<
fALSO >
i just dont remember :-X
16:25
<
KotCzarny >
darn, cant find it
16:26
fkluknav has quit [Remote host closed the connection]
16:27
fkluknav has joined #linux-sunxi
16:31
<
KotCzarny >
not that, but might help you too i guess
16:34
<
arc_phasor >
dang device tree not compiling
16:34
<
arc_phasor >
i wonder if i can't use r-gpio-keys with a regular pio
16:40
leviathanch has quit [Remote host closed the connection]
16:55
jbrown has joined #linux-sunxi
17:06
yann has quit [Ping timeout: 255 seconds]
17:07
Amit_T has joined #linux-sunxi
17:08
reinforce has joined #linux-sunxi
17:10
<
arc_phasor >
hmm... is there a GPIO_KEYS driver i need to support first in the linux kernel
17:10
<
arc_phasor >
still not able to compile the dts
17:18
reinforce has quit [Quit: Leaving.]
17:22
<
arc_phasor >
nope, not finding anything there...
17:25
zoums has quit [Ping timeout: 244 seconds]
17:28
aalm has quit [Quit: xyz 2.3]
17:42
nashpa has quit [Ping timeout: 255 seconds]
17:54
IgorPec has joined #linux-sunxi
17:59
nashpa has joined #linux-sunxi
18:05
clemens3_ has quit [Ping timeout: 244 seconds]
18:11
AneoX_ has joined #linux-sunxi
18:12
Amit_T has quit [Quit: Leaving]
18:12
AneoX has quit [Ping timeout: 255 seconds]
18:14
nashpa has quit [Ping timeout: 246 seconds]
18:15
netlynx has joined #linux-sunxi
18:16
<
arc_phasor >
I've got one of the PL pins working with r-gpio-keys, but trying another pin with gpio-keys gives me "gpio-keys: Unable to get irq number for GPIO 0,"
18:16
<
arc_phasor >
is the regular gpio-keys supported by linux sunxi?
18:20
nashpa has joined #linux-sunxi
18:22
aalm has joined #linux-sunxi
18:22
The_Loko has joined #linux-sunxi
18:25
<
arc_phasor >
got it. I think i was using a GPIO that didn't support EINTs?
18:25
<
arc_phasor >
either way, thanks for the help
18:29
<
mru >
gpio-keys should have a polling mode
18:29
<
mru >
for gpio interfaces that don't support interrupts
18:30
<
mru >
ah, you need to use compabile = "gpio-keys-polled" for that
18:38
IgorPec has quit [Ping timeout: 258 seconds]
18:42
IgorPec has joined #linux-sunxi
18:49
BenG83 has quit [Quit: Leaving]
18:50
<
arc_phasor >
gotcha gotcha
18:50
<
mru >
of course the polling will have some overhead
18:50
<
arc_phasor >
so now that they're showing up in evtest (using interrupts)
18:50
<
mru >
so interrupts are greatly preferred if possible
18:51
<
arc_phasor >
how can i best process these events
18:51
<
arc_phasor >
with my own program
18:51
<
mru >
same as you would any keyboard input
18:51
<
arc_phasor >
i'll need to detect simple hits and a long press of say 4 seconds
18:52
<
mru >
you get key down and key up events
18:52
<
mru >
and optional auto-repeat
18:52
<
arc_phasor >
what does auto-repeat do?
18:52
<
arc_phasor >
if i hold it down it spits out a bunch of events for down?
18:52
<
mru >
generate repeated key-down events if you hold a key presed
18:52
<
arc_phasor >
ok. hmmm
18:52
<
mru >
sometimes useful, sometimes not
18:53
<
arc_phasor >
i could track key down and key up and if it's within 50ms, consider it a tap, otherwise a long press?
18:54
<
arc_phasor >
thinking about using python for this
18:54
<
mru >
sure, that should work
18:59
iamfrankenstein has joined #linux-sunxi
19:07
nashpa has quit [Ping timeout: 244 seconds]
19:10
<
arc_phasor >
hmm for some reason the python script is only recognizing my actual keyboard inputs
19:10
nashpa has joined #linux-sunxi
19:11
<
arc_phasor >
Is there some special python input function i should call to access the raw system keycodes?
19:12
dddddd has quit [Ping timeout: 258 seconds]
19:13
iamfrankenstein has quit [Quit: iamfrankenstein]
19:14
<
mru >
that's reading lines of text from standard input
19:14
<
mru >
not what you want
19:14
<
arc_phasor >
oh geez
19:14
Gerwin_J has joined #linux-sunxi
19:16
<
arc_phasor >
ok thank you
19:27
vagrantc has joined #linux-sunxi
19:29
f0xx has quit [Ping timeout: 245 seconds]
19:39
tllim has quit [Quit: Leaving]
19:43
IgorPec has quit [Ping timeout: 250 seconds]
19:47
Putti has quit [Remote host closed the connection]
20:30
Bortolino has quit [Quit: Page closed]
20:38
arc_phasor has quit [Quit: Page closed]
20:43
BenG83 has joined #linux-sunxi
20:44
dddddd has joined #linux-sunxi
20:44
aep has quit [Quit: WeeChat 2.3]
20:52
iamfrankenstein has joined #linux-sunxi
20:52
iamfrankenstein has quit [Client Quit]
20:56
mzki has quit [Ping timeout: 258 seconds]
20:58
mzki has joined #linux-sunxi
20:59
reinforce has joined #linux-sunxi
21:17
reinforce has quit [Quit: Leaving.]
21:19
netlynx has quit [Quit: Ex-Chat]
21:29
paulliu has quit [Quit: Leaving.]
21:34
tuxillo has quit [Ping timeout: 246 seconds]
22:09
tuxillo has joined #linux-sunxi
22:10
paulk-leonov has quit [Ping timeout: 258 seconds]
22:11
Andy-D has quit [Ping timeout: 245 seconds]
22:11
Andy-D has joined #linux-sunxi
22:51
victhor has joined #linux-sunxi
23:03
BenG83 has quit [Quit: Leaving]
23:08
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
23:20
\\Mr_C\\ has joined #linux-sunxi
23:22
zoums has joined #linux-sunxi
23:40
swiftgeek has quit [Ping timeout: 250 seconds]
23:41
swiftgeek has joined #linux-sunxi
23:42
Rafael1980 has quit [Quit: Konversation terminated!]