cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
cnxsoft1 is now known as cnxsoft
Andy-D_ has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
klarrt has quit [Ping timeout: 250 seconds]
klarrt has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 260 seconds]
TheLinuxBug has joined #linux-sunxi
IgorPec11115 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Client Quit]
zuikis has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec11115 has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Client Quit]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Shirasaka-Hazumi has quit [Quit: ZNC 1.6.2+deb2+b1 - http://znc.in]
staplr has joined #linux-sunxi
Netlynx has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
Shirasaka-Hazumi has joined #linux-sunxi
staplr has joined #linux-sunxi
KotCzarny has quit [Quit: brb]
laga has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 244 seconds]
paulk-collins has joined #linux-sunxi
staplr has joined #linux-sunxi
reinforce has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
IgorPec11115 has joined #linux-sunxi
scream has joined #linux-sunxi
apritzel has joined #linux-sunxi
jernej has joined #linux-sunxi
paulk-collins_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
paulk-collins has quit [Ping timeout: 246 seconds]
Amit_t_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
laga has quit [Remote host closed the connection]
FlorianH has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
sdschulze has joined #linux-sunxi
<sdschulze>
Seems like gmac is broken with Debian's kernel 4.5.0-0.bpo.1-armmp-lpae.
<NiteHawk>
sdschulze: "PHY not found"?
<sdschulze>
libphy: PHY stmmac-0:ffffffff not found
<sdschulze>
OK; for me, I can just go back to 4.4 – but maybe Debian should ship a patch.
<sdschulze>
so people don't break their networking
<NiteHawk>
yes, it's simple enought to revert that specific commit - only needs to be done / addresses. "plain" 4.5 out-of-the box will suffer from this issue
<NiteHawk>
..addressed
<sdschulze>
Maybe someone with a clue should file a Debian bug.
<KotCzarny>
sdschulze: or just use armbian
<KotCzarny>
its plain debian + sunxi specific things in armbian repo
<sdschulze>
It should be fixed in Debian anyway.
jernej has quit [Ping timeout: 260 seconds]
<KotCzarny>
still, armbian is tried and tested for the devices, which might not get such care in debian
<KotCzarny>
and did you try armbian image for your board?
<sdschulze>
You mean, Armbian U-Boot?
<KotCzarny>
if you only need/want uboot, yeah
jstein has joined #linux-sunxi
<sdschulze>
I don't see any hint of this particular patch in the armbian sources; the only patch that concerns GMAC has been backported to mainline Debian, and it's not helping.
<rtp>
iirc, there's already a bug open for the phy not found kernel issue in debian bts
jstein has quit [Remote host closed the connection]
<KotCzarny>
you might just try it, and then post about it if it's still an issue
<sdschulze>
rtp: I see... #823493
<sdschulze>
KotCzarny: The patch, you mean?
<KotCzarny>
the uboot from lime2 image
<sdschulze>
OK, will check.
ricardocrudo has quit [Ping timeout: 260 seconds]
<rtp>
to change the tx delay, one can always mmap() the registers and change the tx delay value. nice for quick testing (but clearly not to be used as a fix)
oneinsect has joined #linux-sunxi
<oneinsect>
Igor
<oneinsect>
is there a way i can generate uimage instead of zimage in armbian
apritzel has joined #linux-sunxi
IgorPec11115 has quit [Quit: Nettalk6 - www.ntalk.de]
Amit_t_ has quit [Ping timeout: 250 seconds]
<sdschulze>
Actually, it works in both the latest Debian and the latest Armbian image.
<KotCzarny>
:)
<sdschulze>
Maybe I didn't reboot after I installed the new Debian U-Boot or something.
<KotCzarny>
hmm, weird
<KotCzarny>
ethernet woes: thinkpad t500--bpim1 works (1gbit), t500-opipc works (100mbit), bpim1--opipc (link negotiated, big packet loss)
<KotCzarny>
anyone got a clue?
<KotCzarny>
yellow light on bpi blinks slowly
<sdschulze>
KotCzarny: This is not, by chance, the GMAC issue?
<oneinsect>
hmmm no idea dont have bpim1 to check
<KotCzarny>
sdschulze, it works when its connected to my laptop, so no
<KotCzarny>
more likely some electric issues
<KotCzarny>
pity i dont have any switch here to check
<KotCzarny>
bpi is seeing the packets and responding, but opipc doesnt see it
<KotCzarny>
funny thing is that arp requests work both ways
<oneinsect>
there were some issues when it was connected to a switch before it booted up
<oneinsect>
i wonder if its solved
<KotCzarny>
but icmp/tcp from bpim1 is not seen by opipc
<NiteHawk>
KotCzarny: the yellow led blinking slowly is normal for the bpi-m1, i think
<KotCzarny>
nitehawk: unlikely, green light is activity
<KotCzarny>
yellow denotes link speed i think
premoboss has joined #linux-sunxi
<KotCzarny>
/usr/local/bin/bpi_ledset eth0 ylm gh ba; # yellow for 10/100, green for 1000, blue for act
<premoboss>
hello, i need to enable a not-root user to use "dd". only dd, not other commands. there is a vay to do it withoud to add user to sudo?
<KotCzarny>
premoboss: dd on what?
<premoboss>
"dd" on /dev/sdX
<KotCzarny>
because if you want to give user access to partitions, you can simpy chown /dev/sdX
<premoboss>
to chown /dev/sdx it seems to much, can i insead work on dd?
<premoboss>
insead=instead
<igraltist>
try as user: touch /hallo
<sdschulze>
premoboss: A user who can do dd can do pretty much anything. But apart from that, sudo can allow users to use specific commands.
<igraltist>
has nothing to do with dd, the user does not have the rights
jernej has joined #linux-sunxi
<premoboss>
sdschulze, it is a "special" machine, the user will be also the only usr, so it can be "root".
<premoboss>
but to take separate the situagionn root / not-root, i was looking to mace use ael tu use only dd.
<sdschulze>
premoboss: Then what's wrong with adding this user to sudoers?
<KotCzarny>
premoboss: if you give user access to dd(root), user can do practically anything
<premoboss>
sdschulze, never did before :-( i need that user can do "dd" without give password ... is possible?
<KotCzarny>
unless you prepare scripts and add user to use those scripts without params
<premoboss>
in this particular case, user MUST be able to use dd to read/write at low level on disks with no care to partitions.
<sdschulze>
In Debian, it's usually recommended to just add the user to the sudo group.
<premoboss>
but if i add user to sudo group, than he can do all. istead i need it to use only dd. yes, to use dd allow to do almost all, but not all 100%.
<premoboss>
at least it is more complecated.
<apritzel>
premoboss: it's risky, because as already mentioned dd is dangerous, but what you are looking for is: chmod u+s /usr/bin/dd
<apritzel>
but I'd prefer the sudo way as well
<KotCzarny>
apritzel, its more dangerous
<premoboss>
apritzel, yes it is riscy, but it it is a mono-used PC dedicated to ONE applicatio in local only, no internet, no nothing. it is a develop pc ant it is "lostable".
<KotCzarny>
that way you give it access to everything, not just specified partition
<apritzel>
KotCzarny: if that's what he wants ...
<premoboss>
i fount this command to ad to sudo file with visudo: joe ALL=(ALL) NOPASSWD: /full/path/to/command
<KotCzarny>
one can patch any part of the filesystem with dd to escalate to root
<premoboss>
i take apritzel suggestion as good, but first i try the sudo way.
<apritzel>
indeed, so the safest solution would be to grant access to the block device
<apritzel>
and use a non-setuid dd
<KotCzarny>
or creating custom app that would allow specific things
<KotCzarny>
apritzel: do you have any idea for bpim1--opipc ethernet problem i have?
<premoboss>
but the user must "dd" the free space of disk, thare is not partition there. is some like: dd if=/dev/sda of=/dev/shm/123.tmp ibs=1 skip=12312312312312 count=200
<KotCzarny>
premoboss: it's done another way
<KotCzarny>
dd </dev/zero >somefile bs=4k
<KotCzarny>
if you only want to zero free space
<apritzel>
KotCzarny: are you connecting OPi and BPi directly or via a switch?
<KotCzarny>
apritzel: directly, but they both work when connected directly to thinkpad t500
<KotCzarny>
unless opipc has problems with 100mbit
<premoboss>
i have not to het /dev/zero but /dev/sda starting from a particoular byte for a partocoularl length in byte. i MUST read those byte, not zero.
<KotCzarny>
premoboss: then create a simple app that will check given params and do that, then add it to sudoers for user
<premoboss>
KotCzarny, good idea.
<premoboss>
i can do a simply C programm that do it, and then to ad to sudo... good idea.
<apritzel>
if it is about read access only to the whole harddrive, try: setfacl -m g:<group>:r /dev/sda
sdschulze has quit [Quit: Verlassend]
<apritzel>
replacing <group> with the default group name of the user
<KotCzarny>
apritzel: hrm, setting t500 to 100mbit still works, so its not autoneg or any particular speed
<KotCzarny>
all i can think now is some electro noise
<apritzel>
isn't autoneg a Gigabit feature?
<KotCzarny>
nope
<KotCzarny>
10/100/1000, hd/fd
<NiteHawk>
but MDI/MDI-X is, or? with two 10/100 interfaces, a cross-over cable may be required?
<NiteHawk>
but since the bpi has gigabit, that shouldn't be an issue - given/assuming that autonegotiation works as expected
<apritzel>
err, forget it, the BPi should do that: both autoneg down to 100Mbit and also the cross/non-cross detection
<KotCzarny>
nitehawk: hrm, might be mdi/mdi-x issue
<apritzel>
KotCzarny: NiteHawk: I think MDI-X detection should work if one peer is a Gigabit one
<KotCzarny>
drat, dont have crossover cable to check
<apritzel>
KotCzarny: yeah, those are rare these days ;-)
<NiteHawk>
KotCzarny: you don't have a switch around? might be interesting to see what happens if you hook all three (including the thinkpad) up to a switch and test them pairwise
<KotCzarny>
[root@banana 13:37:19 /1/_src/n8x0/root_fs/1/_src/debian/openssl/diffs]# ethtool -s eth0 mdix on
<KotCzarny>
setting MDI not supported
<KotCzarny>
banana doesnt support mdix
<KotCzarny>
and now i know its cable issue
<apritzel>
KotCzarny: might be a driver issue?
<KotCzarny>
aptritzel: kernel 4.5.0-rc3
<KotCzarny>
hrm, maybe i have crossed cable somewhere deep in the closet
cnxsoft has quit [Quit: cnxsoft]
<apritzel>
KotCzarny: look in that box label "1990's cables" :-P
<apritzel>
*labeled*
<NiteHawk>
at least that rules out RG58 :D
nove has joined #linux-sunxi
<KotCzarny>
anyway, weird that bpim1/opipc dont support mdix
<KotCzarny>
in this day and time
<KotCzarny>
can anyone else check if its the case or just bad kernel version?
<NiteHawk>
KotCzarny: it's also quite possible that noone bothered to implement it driver-side?
<KotCzarny>
nitehawk: where can i post the bugreport?
<apritzel>
NiteHawk: that's was I was thinking too ...
<NiteHawk>
KotCzarny: at least i can confirm your observation: "ethtool -s eth0 mdix auto" (or whatever) complains "setting MDI not supported"
IgorPec11115 has quit [Ping timeout: 276 seconds]
<NiteHawk>
(that's with linux 4.4.6-gentoo, but i suspect kernel version won't matter much here)
<KotCzarny>
who is stmmac maintainer?
<KotCzarny>
or developer
apritzel has quit [Ping timeout: 244 seconds]
<NiteHawk>
get_maintainer spits out stuff like: Giuseppe Cavallaro <peppe.cavallaro@st.com> (supporter:STMMAC ETHERNET DRIVER), netdev@vger.kernel.org (open list:STMMAC ETHERNET DRIVER), linux-kernel@vger.kernel.org (open list)
<KotCzarny>
ok, dont know any of these guys being irc users, gmac maintainer then?
<KotCzarny>
Newer routers, hubs and switches (including some 10/100, and all 1 gigabit or 10 gigabit devices in practice) use auto MDI-X for 10/100 Mbit connections to automatically switch to the proper configuration once a cable is connected.
<KotCzarny>
Gigabit and faster Ethernet links over twisted pair cable use all four cable pairs for simultaneous transmission in both directions. For this reason, there are no dedicated transmit and receive pairs, and consequently, crossover cables are never required for 1000BASE-T communication.[8] The physical medium attachment sublayer (PMA) provides identification of each pair and usually continues to work even over cables where the pairs are unusually swapped
<KotCzarny>
mdi-x is for 10/100, gigabit autoconfigures tx/rx pairs on the go
<NiteHawk>
so, did you test a switch inbetween bpi and opipc?
<KotCzarny>
i dont have one here
<KotCzarny>
but i guess anyone with 2 sunxi based devices can check
<NiteHawk>
if that works, and the direct connection doesn't - then you've likely narrowed down the problem
<KotCzarny>
or with x86 device mdix off setting
<NiteHawk>
you could examine the (ethtool) MDI-X status on your thinkpad when connected to the bpi?
<KotCzarny>
unfortunatelly it has windoze
<NiteHawk>
ha!
<KotCzarny>
its my 'gaming' rig, what can i say *blushes*
<NiteHawk>
i'll try to hook up the bpi to my notebook... /me has multiboot :P
<KotCzarny>
thx :)
scream has quit [Remote host closed the connection]
<NiteHawk>
KotCzarny: hrrrm... unfortunately my acer only reports "unkown" status and doesn't support setting MDI-X either. but i allows me to ssh into the bpi with a direct connection
<KotCzarny>
is it 1gbit?
Andy-D has joined #linux-sunxi
<NiteHawk>
yes. and i notice that while i have the "normal" blinking of the amber bpi network led when connected to my (gbit) switch, it's constantly lit with the direct link - so the bpi seems to notice some difference
<KotCzarny>
all gbit devices have mdi-x
<NiteHawk>
it's probably just "auto", and the ATL1E driver doesn't support querying or changing it?
<KotCzarny>
yup
<NiteHawk>
at least it shows up in the ethtool output (with the transceiver being "internal"). i just can't set it
<KotCzarny>
but i find it weird you own only 1 sunxi device
<NiteHawk>
the pine64 is not fully ready yet :P
oneinsect has left #linux-sunxi [#linux-sunxi]
<KotCzarny>
still, only 2 sunxi devices? :P
<KotCzarny>
btw. do you have any usb-eth dongle?
<KotCzarny>
they are usually 100mbit max
<NiteHawk>
err... think so, but don't ask me which pile that might be hiding under :D
<KotCzarny>
:)
<KotCzarny>
i think uboot author is emac author too
<KotCzarny>
but. without mdi-x devices wouldnt finish autonegotiation, would they?
<KotCzarny>
also, opipc->bpi works (packets are seen and received ok), but bpi->opipc packets fail
<KotCzarny>
and SOME packets manage to come back with 10mbit-HD, 60% packet loss
<NiteHawk>
KotCzarny: hard to tell. if things like autoneg fail, they tend to fail in rather unpredictable ways... :)
<KotCzarny>
it doesnt fail, when i force it on bpi it also changes on opi
<KotCzarny>
and with 8byte icmp 'only' 9% packet loss
IgorPec11115 has joined #linux-sunxi
scream has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
IgorPec11115 has quit [Ping timeout: 265 seconds]
Mr__Anderson has joined #linux-sunxi
<Mr__Anderson>
Hello, did anybody try to compile kernel 4.5 on the Allwinner A83T ?
FlorianH has quit [Quit: Leaving]
FlorianH has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<willmore>
KotCzarny, keeping a Windows box for gaming? I share your shame. Some day...
FlorianH has quit [Quit: Leaving]
adminf has joined #linux-sunxi
hu8h90 has joined #linux-sunxi
zuikis has quit [Remote host closed the connection]
hu8h90 has quit [Quit: Leaving]
Nacho has joined #linux-sunxi
Nacho_ has quit [Ping timeout: 240 seconds]
arnd has quit [Ping timeout: 244 seconds]
arnd has joined #linux-sunxi
apritzel has joined #linux-sunxi
<KotCzarny>
montjoie: does your driver support mdi-x ?
IgorPec has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
<Amit_t_>
Hello. where can I get pine64 board schematics
<apritzel>
and then talk I2C to this guy, setting DC1SW to on (bit 7, register 0x12)
<Amit_t_>
This is actual ouput
<Amit_t_>
ok
<apritzel>
NiteHawk: thanks for that hint
<NiteHawk>
well... i can pass it to Amit_T, who got me searching through it :D
<apritzel>
so if anyone knows about the clock and reset gates for S_TWI (aka secure I2C), I am all ears ...
<apritzel>
afk ...
<Amit_t_>
Hmm.. I have to again change the direction my experiment.
<Amit_t_>
apritzel: need some time to decode all that what you said.
apritzel has quit [Ping timeout: 244 seconds]
apritzel has joined #linux-sunxi
<montjoie>
KotCzarny: I think the support is in PHY
ptx0 has joined #linux-sunxi
<NiteHawk>
apritzel: the A64 datasheet lists PL0 and PL1 for S_TWI_SCK / S_TWI_SDA. This corresponds nicely with the schematics page 5, where they're shown to connect as "PMU-SCK" and "PMU-SDA" - i take that we're looking at "PL" configuration registers then? (PL_CFG0_REG etc.)
<montjoie>
I never think anything MDIX related in ethernet drivers
<NiteHawk>
apritzel: or are you taking about the axp803 side of things?
<NiteHawk>
..talking
<KotCzarny>
montjoie: hrm
Gerwin_J has joined #linux-sunxi
RzR has quit [Ping timeout: 244 seconds]
jernej_ has quit [Ping timeout: 276 seconds]
apritzel has quit [Quit: Leaving.]
apritzel has joined #linux-sunxi
<apritzel>
NiteHawk: yeah, that part is clear
ikmaak has quit [Remote host closed the connection]
<apritzel>
but I wonder if there is a clock bus gate bit as there is for the other I2C controllers
<NiteHawk>
yes, i can see what you mean. i'm digging into the a64 user manual and documentation for S_TWI is "sparse" to put it politely
<apritzel>
indeed
Andy-D has quit [Ping timeout: 246 seconds]
<apritzel>
maybe the clock is always enabled for that controller?
<apritzel>
I am going to try it by hacking something into the kernel
ikmaak has joined #linux-sunxi
<apritzel>
we need a R_PIO pinctrl for that
Andy-D has joined #linux-sunxi
<NiteHawk>
my impression is they tend to leave out (or shorten) things that have been done similarly in earlier SoCs, assuming readers are already familiar with "the Allwinner way"?
<ssvb>
apritzel: it should be possible to dump all the relevant registers with and without active arisc firmware and then compare the settings
premoboss has quit [Quit: Sto andando via]
<apritzel>
ssvb: mmh, good idea, I guess I should just use U-Boot's mw.l command and try to talk to the I2C controller directly
jstein has joined #linux-sunxi
<wens>
apritzel: no, S_TWI has a clock gate, like RSB
<wens>
it's part of the PRCM block
<apritzel>
btw: is the manual wrong or is the SUN8I_H3_R pinctrl "driver" buggy?
<apritzel>
wens: which isn't documented?
<wens>
apritzel: seems that way
<wens>
PRCM also has a bunch of power controls, for CPU and GPU
<wens>
also, the RSB controller can send an i2c write-like command telling all slaves on the bus to switch to RSB
* apritzel
seems to get used to that Allwinner way: look into other SoC's manuals ;-)
<apritzel>
so A31 has an PRCM section
<wens>
apritzel: socs later than (not including) a20 all have it
<wens>
and the register maps are pretty similar
<apritzel>
wens: OK, found something in the A23 manual (sigh!)
<NiteHawk>
see? ;)
pmattern has joined #linux-sunxi
<Amit_t_>
wens: clock gating for H3 TWI is part ccu's Bus Clock Gating Register3 ?
jernej_ has joined #linux-sunxi
<apritzel>
oh, the H3-R pinctrl driver is fine, I was just looking at the wrong file (sun8i-a23-r.c)
<apritzel>
Amit_t_: for the three normal I2C controllers: yes
<wens>
Amit_t_: that is TWI, not S_TWI
<wens>
all the new socs also have separate r block pin controller
<Amit_t_>
ok
<apritzel>
wens: do you know of a good manual in respect to PRCM documentation?
<wens>
the R block stuff is for secure world, likely openrisc core
<apritzel>
the A23 comes close, but I see a reserved bit being set
<wens>
what reserved bit?
<Amit_t_>
wens: got it .
<wens>
there is no complete doc for PRCM
* apritzel
was afraid you would say that :-(
<wens>
a23, a31, a80, a83 are the ones that have it
<apritzel>
01f01428: 00000089
<apritzel>
=> md.l 0x1f01428 1
<apritzel>
which has bit 7 set, which is reserved in the A23 manual
* apritzel
is looking at A83 now ...
ojn_ has joined #linux-sunxi
<wens>
bit 7 on a80 is r_twi1
<apritzel>
looks better, bit 7 is R_TWD there (whatever that means)
<wens>
apritzel: trusted watchdog
<apritzel>
rightttt
ojn has quit [Ping timeout: 244 seconds]
ojn_ is now known as ojn
<Amit_t_>
apritze: are you trying to enable this controller from ATF ?
<apritzel>
wens: do you have an A80 manual with PRCM?
<wens>
apritzel: available on allwinner's github
<apritzel>
wens: cheers, so it's a newer version there than at the Wiki
<apritzel>
gee, that one has quite some details; at least it seems that the R_TWI clock gate is bit 6 consistently
<Amit_t_>
sorry to intervene but one doubt can these secure block be access from EL2 on ARM64 ?
<apritzel>
Amit_t_: my hunch is that this can be configured
<apritzel>
via the secure peripherals controller
<apritzel>
the default (and what the ATF code sets up) is to grant access to non-secure
<wens>
secure peripherals controller section says PRCM is switchable
<wens>
pretty much the whole r block is switchable
<wens>
excluding secure sram and watchdog
<wens>
see section 3.17 of the a64 manual
<apritzel>
but that just isn't true, as I can write to SRAM A2 from (EL2) U-Boot
<wens>
not sure how the arm64 execution levels map to this
zuikis has joined #linux-sunxi
<wens>
i'm off to bed
<apritzel>
wens: sleep well!
<Amit_t_>
hmm..so it can be done from u-boot as well
<Amit_t_>
wens: good night .
<apritzel>
at least it seems I can't access the secure controller from U-Boot, which is good
<Amit_t_>
but I guess I still access rsb from u-boot .need to find a way to configure axp803 now
<Amit_t_>
which we any need to anyway configure in case of S_TWI as well
avph has quit [Ping timeout: 260 seconds]
<apritzel>
Amit_t_: be careful with that!
<Amit_t_>
you mean board can blown off ?
<apritzel>
Amit_t_: and my plan is to setup the AXP in ATF
<apritzel>
Amit_t_: yes
<apritzel>
read registers first, check that the content makes sense
<Amit_t_>
ok
<apritzel>
you can easily verify with a multimeter
<Amit_t_>
don't know how to use it :(
<apritzel>
measure the voltage on the Pi-"bus"
<apritzel>
you then can slightly adjust the voltage of DCDC1
<apritzel>
and should be able to measure it
<Amit_t_>
ok, your plan is to access axp from s_twi, right ?
<apritzel>
yes, I hacked the DT, so I should be able to access the I2C from Linux
<apritzel>
using i2ctools
<apritzel>
so I could do experiements from there
<apritzel>
once I am sure this works, I will add something to ATF
<Amit_t_>
but then you'r running in el2?
RzR has joined #linux-sunxi
<Amit_t_>
I am confused again
<apritzel>
so what?
<apritzel>
R_TWI is "switchable"
<apritzel>
and reset to non-secure
<apritzel>
whatever this _really_ means
<Amit_t_>
oh you would first switch it as pointed by wens ?
<Amit_t_>
ok
<apritzel>
ATF resets all peripherals to non-secure
<apritzel>
there is no security at the moment ;-)
<Amit_t_>
same you will tell linux do :)
<Amit_t_>
*Linux to do.
<apritzel>
if that regulator setup works, I will switch R_TWI to secure
<Amit_t_>
fine but do we axp803 driver ?
<apritzel>
I hope we get away without one at the moment
<Amit_t_>
which I couldn't find anywhere
<Amit_t_>
ok
* apritzel
is off to dinner
<Amit_t_>
ok, Thanks for discussion.
apritzel has quit [Ping timeout: 244 seconds]
jinzo has joined #linux-sunxi
raknaz has joined #linux-sunxi
jernej_ has quit [Ping timeout: 276 seconds]
<KotCzarny>
hrm, i've lost /sys/power/axp_pmu/, where is it enabled? (mainline)
jstein has quit [Remote host closed the connection]
jstein has joined #linux-sunxi
raknaz1 has joined #linux-sunxi
raknaz has quit [Ping timeout: 240 seconds]
raknaz1 is now known as raknaz
raknaz has quit [Quit: raknaz]
jstein has quit [Remote host closed the connection]
VargaD has quit [Ping timeout: 276 seconds]
VargaD has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
jernej_ has joined #linux-sunxi
Amit_t_ has quit [Quit: Page closed]
IgorPec has quit [Ping timeout: 276 seconds]
avph has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
avph_ has joined #linux-sunxi
nove has quit [Quit: nove]
Andy-D has joined #linux-sunxi
<KotCzarny>
hmm, yet another reason to drop the 3.4. hitting futex_wait deadlock :/
paulk-collins_ has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
Mr__Anderson has quit [Quit: Leaving.]
zuikis has left #linux-sunxi [#linux-sunxi]
scream has quit [Remote host closed the connection]