Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
NeuroScr has quit [Quit: NeuroScr]
Da_Coynul has joined #linux-sunxi
kilobyte_ch has quit [Ping timeout: 246 seconds]
kilobyte_ch has joined #linux-sunxi
craigo has quit [Ping timeout: 272 seconds]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
cnxsoft has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
megi has quit [Ping timeout: 272 seconds]
TheSeven has quit [Ping timeout: 264 seconds]
[7] has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 258 seconds]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 258 seconds]
lurchi_ is now known as lurchi__
florian has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
[7] has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
Danct12__ has joined #linux-sunxi
Danct12_ has quit [Ping timeout: 268 seconds]
xqdzn has joined #linux-sunxi
lykt has quit [Quit: leaving]
<xqdzn>
Guys, is it best practice to change value in processor level instead of board level device tree? Because I can't change display_engine { status = };
<xqdzn>
*I can't change it from board level dts
fl_0 has quit [Ping timeout: 252 seconds]
lykt has joined #linux-sunxi
fl_0 has joined #linux-sunxi
florian has quit [Ping timeout: 245 seconds]
<jernej>
for your own experiments, that's fine, but if you mean to sent DT change upstream, you have to put such changes in board DT
<xqdzn>
But I can't simply do the same for "display_engine" or "de"
<jernej>
why not? did you check other board DTs with H2+ or H3?
<xqdzn>
When I compile to dtb, the compiler said couldn't find "display_engine" or "de"
<jernej>
for H2+, it should be de
<jernej>
and it's present for a long time
<xqdzn>
Nvm, I did it. Maybe I messed up with processor dts. I tried to clone fresh source from upstream. then put &de { status = "okay"; };. Compile it, then it works.
AneoX has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 248 seconds]
GrimKriegor has joined #linux-sunxi
GrimKriegor has quit [Changing host]
GrimKriegor has joined #linux-sunxi
gsz has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
<xqdzn>
Guys, I'm about to enable thermal sensor on board level (sun8i-h2-plus-bananapi-m2-zero.dtb) device tree. But the compiler said: "label or path not found for ths (&ths)" but when i do it in processor level, it makes another device tree
<xqdzn>
*but when i do it in processor level, it makes another device tree error
<KotCzarny>
thermal sensor is just enabling proper module
<KotCzarny>
ie. compile it in
<xqdzn>
I searched from board to processor level, none of them defining thermal zones
<xqdzn>
Oh btw, i got HDMI, Ethernet, eMMC, i2c working so far. Thank you KotCzarny!
pmp-p has quit [Ping timeout: 248 seconds]
<xqdzn>
https://gist.github.com/xqdzn/e9112f53e9ac8d392972441c96512b62 For temperature and hysteresis, i could do it by converting to integer first so it would compiled to hexadecimal properly. But when it comes into phandle, cooling-device, i dont' know what to do
pmpp has joined #linux-sunxi
quadjfet has quit [Remote host closed the connection]
_whitelogger has joined #linux-sunxi
nexgen has quit [Remote host closed the connection]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
dddddd has joined #linux-sunxi
xqdzn has joined #linux-sunxi
nexgen has quit [Quit: Leaving]
Da_Coynul has joined #linux-sunxi
afaerber has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
kilobyte_ch has quit [Ping timeout: 268 seconds]
lurchi__ is now known as lurchi_
kilobyte_ch has joined #linux-sunxi
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
ninolein has joined #linux-sunxi
megi has quit [Ping timeout: 268 seconds]
Da_Coynul has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
scelestic has quit [Remote host closed the connection]
scelestic has joined #linux-sunxi
Maxit has joined #linux-sunxi
Danct12__ has quit [Remote host closed the connection]
Danct12__ has joined #linux-sunxi
<Maxit>
hi all! orangepi zero problem with i2c
<Maxit>
i nreally nedd help
<Maxit>
all online tutorial ar not helpful
<Maxit>
my kernel is:
<Maxit>
Linux orangepizero 4.19.62-sunxi #5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l GNU/Linux
<Maxit>
is it normal to not see i2c-dev on lsmod after a modprobe?
cnxsoft has quit [Quit: cnxsoft]
<Maxit>
heeeeeeeeeeelp please
<montjoie>
Maxit: did you try modprobe i2c-dev ?
tlwoerner has quit [Quit: Leaving]
<Maxit>
yes, a use modprobe i2c-dev, but after lsmod i cannot show module, is it normal?
<lurchi_>
compiled in?
<Maxit>
sorry=
<Maxit>
?
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
Danct12__ has quit [Ping timeout: 245 seconds]
<montjoie>
Maxit: zgrep I2C /proc/config.gz
<montjoie>
you should see some i2c dev config
lurchi_ is now known as lurchi__
<libv>
so the module does not show in lsmod...
<libv>
is the singular goal to have it show up in the list of loaded modules, or is the plan to actually use i2c?
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Danct12__ has joined #linux-sunxi
<martinayotte>
I2C are not enabled by default in DT. No needs to do 'modprobe', with Armbian, we use overlay to enable I2C and the module is loaded automatically by compatible.
<xqdzn>
Because my next question is: What kind of feature that we could leave to user to decide? Let's say, HDMI, some user might doesn't need it. Should it put in DT Overlays instead of compiled as default in DT ?
<xqdzn>
*Should we put it...
<libv>
hdmi only gets brought up when hotplug is there
<xqdzn>
what about i2c ? Should we let user decide?
<xqdzn>
Or WiFi, some people might just want to use ethernet only.
<KotCzarny>
check what armbian does
<libv>
then don't load the driver
<KotCzarny>
they have sensible defaults often
<libv>
you do not need any dt work for that
<KotCzarny>
and anyone having particular needs, will know how to change defaults
skiboy has joined #linux-sunxi
<martinayotte>
xqdzn: not exactly ... Mainline guys would say if some peripheral pins have multiple purposes, such I2C/GPIO or SPI/GPIO or even UART/GPIO, they should stay as GPIO by default and enabling auxiliary peripherals with overlays. For HDMI, they don't have auxiliary peripheral, so no needs to disable them by default.
<martinayotte>
Same applies for ETH or WiFi.
<xqdzn>
wait, let me google about auxiliary peripheral first.
<libv>
xqdzn: most development boards come with a header exposing io pins which are muxed
<martinayotte>
Right ! muxed == shared !
<libv>
xqdzn: while it can be argued that one should be able to select the function of such pins from userspace, often it is hardwired in dt today
<xqdzn>
Hmm.. Because my fave distro, doesn't seem has "DT Overlays feature" like armbian does, that means we either have to make it enabled by default or disable. But I like this "anyone having particular needs, will know how to change defaults"
<KotCzarny>
arch has a bunch of nice wiki docs
<buZz>
xqdzn: which distro is that?
<KotCzarny>
in the worst case you can contribute if it gets in a weird way
<xqdzn>
archlinuxarm
<buZz>
archlinux uses that old kernels?
<KotCzarny>
you could also start a page on linux-sunxi wiki
<buZz>
afaik all modern kernels can do DT and overlays
<KotCzarny>
google finds a way then
<xqdzn>
wait, I think i get "DT Overlays" feature in a wrong way.
<xqdzn>
Overlaying DTB file is working in archlinux
<buZz>
device tree binaries, yeah
<xqdzn>
but something like putting parameter in armbianEnv.txt, i dont think so.
<martinayotte>
BTW, there are 2 ways to load overlays : normal way is done by U-Boot and the other is dynamically with /sys/kernel/config/device-tree/overlays
<buZz>
xqdzn: environment variables? eh?
<xqdzn>
because they have customed u-boot to support that armbianEnv.txt, i suppose.
<buZz>
doubt it
<buZz>
armbian isnt that magic :P
<KotCzarny>
but they had customized uboot confg/scripting
<buZz>
uboot can execute scripts, yeah
<xqdzn>
aight, so I get it right this time. Correct me guys:
<martinayotte>
parameters in /boot/armbianEnv.txt is handled by overlay fixup script. This is to avoid having almost the same overlays for multiple devices, such SPI0/SPI1
<xqdzn>
When we add “dtparam=spi=on” to your /boot/config.txt in raspi, the bootloader will read that parameter and do particular stuff to overlay the required dtb files. So the feature would be configure (on/off). << Is this correct?
<KotCzarny>
thst's raspi specific
<xqdzn>
yeah, but am i right?
<KotCzarny>
i've never used raspi
<KotCzarny>
:)
<xqdzn>
so the armbian guy do pretty much the same, they make u-boot support that armbianEnv.txt, then will do particular procedure based on parameter written in armbianEnv.txt << Is this right?
<martinayotte>
RasPi way is different way than Armbian, but it is up to the distro to decide "how" parameters are handled. Sometime there is no needs for parameters, but in some cases is is avoiding redundancies, such W1-GPIO here GPIO pins can be any of ones available.
<Maxit>
i am sorry for late response... i was out...
<Maxit>
i am not always in front of monitor today...
<martinayotte>
Maxit: is your distro is Armbian ? If Yes, then simply add "overlays=i2c0 i2c1" in /boot/armbianEnv.txt and you will get those two i2c ports enabled ...
<Maxit>
i already have overlays=i2c0 i2c1 i2c2 usbhost2 usbhost3
<Maxit>
i used armbian-config to enable i2c...
<xqdzn>
martinayotte, hmm.. I see..
<martinayotte>
Ok ! Then, you should have them already working. Did you install i2c-tools ? what "i2cdetect -l" is reporting ?
<Maxit>
this is the device list:
<Maxit>
i2c-2 i2c mv64xxx_i2c adapter I2C adapter
<Maxit>
i2c-1 i2c mv64xxx_i2c adapter I2C adapter
<Maxit>
i2c-0 i2c mv64xxx_i2c adapter I2C adapter
<xqdzn>
Maxit how do you check i2c is working or no? because i got it kind of tricky last time i work with it.
<libv>
Maxit: do not paste such things in the channel
<martinayotte>
What are you devices ? Do you have pullups on the bus ?
<libv>
Maxit: use pastebin
<xqdzn>
Maxit what the result of: ls /dev/i2c* ?
<Maxit>
xqdzn: i am sure that i2c device is working because it is an arduino that i tryed before with another arduino
<Maxit>
root@orangepizero:~# ls /dev/i2c*
<Maxit>
/dev/i2c-0 /dev/i2c-1 /dev/i2c-2
<martinayotte>
Maybe you're not looking at the right bus ?
<Maxit>
no pullup
<martinayotte>
No pullups make the bus not working, because all devices are open-collector.
<xqdzn>
martinayotte: Is it up to mainline guys when will the patch included in source? because I see patches from 2016 and can't see anything about it in latest source
<martinayotte>
Some boards provide pullups by default, some not.
<Maxit>
the only thing disturbe me is that arduino work on 5v and pi on 3.3
<xqdzn>
Maxit you got your i2c0, i2c1, i2c2 enabled. You just have to make sure it connected properly (cabling)
<Maxit>
but... i read that master i2c decides voltage
<xqdzn>
Maxit what device are you trying to use? OLED?
<Maxit>
no..arduino nano
<Maxit>
xqdzn: device is arduino nano
<xqdzn>
from your result, i dont see any problem, your i2c(s) is working. Can you draw how you arrange the cable ?
<martinayotte>
if devices are 5V, then you need voltage-level shifters
<Maxit>
xqdzn: only 2 cable, sda, scl of arduino connected direct to pin 5 and 6 of PI
<martinayotte>
voltage-level shifters could be made using MOSFETs
<Maxit>
martinayotte: everywhere i read that voltage level shifter no need......
<xqdzn>
Maxit what pi are you using? what board?
<martinayotte>
Not true ! You can damage your Pi ...
<Maxit>
martinayotte: ok... i'll try directly with arduino 3.3v
<xqdzn>
So it's not applied to the source but it's applied, then it got replaced by new one, is it?
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<martinayotte>
I'm not following all patches details, there are so much ... I'm reading ML in diagnonal to save time ... :-P
<anarsoul>
xqdzn: I'm not sure what you're talking about
<xqdzn>
In the patch mailing list, i saw "...../devicetree/bindings/thermal/sunxi-ths.txt ..." that means the patches generated files, one of them is sunxi-ths.txt, right?
return0e has quit [Ping timeout: 248 seconds]
Da_Coynul has joined #linux-sunxi
return0e has joined #linux-sunxi
<xqdzn>
But i can't find that file in source, nor even sun8i-thermal.yaml
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Client Quit]
vagrantc has joined #linux-sunxi
rexxster has quit [Remote host closed the connection]