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