<KotCzarny>
there is nothing else in the email? o.o
<MoeIcenowy>
KotCzarny: yes
<KotCzarny>
maybe in the source?
mosterta|2 has quit [Read error: Connection timed out]
staplr has joined #linux-sunxi
mosterta|2 has joined #linux-sunxi
<plaes>
KotCzarny: he is sending from outlook.com address :P
<KotCzarny>
lol
<KotCzarny>
all-time favourite m$ philosophy 'too much info can hurt the luser'
<KotCzarny>
;)
IgorPec has quit [Ping timeout: 244 seconds]
reinforce has joined #linux-sunxi
tsuggs has joined #linux-sunxi
<MoeIcenowy>
and should patches about sunXi soc be cc-ed to linux-sunxi@googlegroups.com ?
<plaes>
yeah, it would be nice
staplr has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
and if one patch of my patchset is device tree binding doc, should I cc the full patchset to devicetree@vger.kernel.org?
<MoeIcenowy>
or only the part?
<plaes>
lets say you have a list of patch files
<plaes>
you get the addressees via: scripts/get_maintainer.pl *.patch
<plaes>
and then submit whole patchset to everyone listed by get_maintainer.pl
<MoeIcenowy>
whom should be contained in the "to" slot?
<MoeIcenowy>
(others in the "cc")
<plaes>
I usually put the maintainers there
<plaes>
and cc the mailing lists and other non-maintainers
leilei has quit [Remote host closed the connection]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
cosm has quit [Quit: Leaving]
iaglium has quit [Ping timeout: 276 seconds]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy 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/]
Zliba has quit [Ping timeout: 264 seconds]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
alexxy has quit [Quit: No Ping reply in 180 seconds.]
xalius has joined #linux-sunxi
alexxy has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<t00thless>
hi, is there anyone who try to compile sunxi linux with grsecurity?
Amit_t_ has quit [Ping timeout: 250 seconds]
Amit_t_ has joined #linux-sunxi
<montjoie>
planned to try, but grsec for arm is not really supported ?
<montjoie>
and since grsec doesnt care about drivers/*, I see no obstacle to use grsecurity with any sunxi board
jernej has quit [Ping timeout: 276 seconds]
kasper has joined #linux-sunxi
kasper has quit [Read error: Connection reset by peer]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
kasper has joined #linux-sunxi
kasper has quit [Max SendQ exceeded]
kasper has joined #linux-sunxi
kasper has quit [Max SendQ exceeded]
kasper has joined #linux-sunxi
staplr has joined #linux-sunxi
kasper has quit [Ping timeout: 240 seconds]
zuikis has joined #linux-sunxi
<MoeIcenowy>
oh I found it ghost.
<MoeIcenowy>
I cannot make anything appear in the linux-kernel mailing list
<MoeIcenowy>
(I used Cc
<MoeIcenowy>
only the response of bbrezillon appeared in the mailing list
jernej has joined #linux-sunxi
<NiteHawk>
MoeIcenowy: you're talking about your "reset" series? that seemed to show up just fine on the ML
<NiteHawk>
(I just received v3)
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
<MoeIcenowy>
NiteHawk: thx
<MoeIcenowy>
(I made a serious error in v2
<MoeIcenowy>
more serious than the error in v1 that I fixed :-)
<bbrezillon>
MoeIcenowy: what was the error in v2?
<bbrezillon>
MoeIcenowy: ok, got it
<bbrezillon>
MoeIcenowy: you should wait a bit before sending new versions of your patchsets
<bbrezillon>
;)
<MoeIcenowy>
bbrezillon: ok.
<bbrezillon>
and it's
<bbrezillon>
} else if (...) {
<bbrezillon>
not
<bbrezillon>
}
<bbrezillon>
else if (...) {
<bbrezillon>
MoeIcenowy: checkpatch should complain
<bbrezillon>
shouldn't you reassert the reset in case of errors?
mpmc has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
bbrezillon: thanks.
<MoeIcenowy>
I may test it tomorrow.
mpmc has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
(I don't know how to use checkpatch before this
<bbrezillon>
MoeIcenowy: and in the ->remove() hook
<MoeIcenowy>
Orz
<MoeIcenowy>
bbrezillon: yes.
<bbrezillon>
you know how to use it now?
<bbrezillon>
it's pretty simple
<MoeIcenowy>
yes.
<bbrezillon>
when you're in the kernel tree => scripts/checkpatch.pl <your-patch>
<MoeIcenowy>
thx
Amit_t_ has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Quit: cnxsoft]
<MoeIcenowy>
bbrezillon: what does "ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit added5fce61e ("ARM: mxs_defconfig: add CONFIG_USB_PHY")'" means?
Amit_t_ has joined #linux-sunxi
<bbrezillon>
It means you're referencing an existing commit in your commit message, but are not using the correct format
jstein has quit [Ping timeout: 250 seconds]
cptG_ has joined #linux-sunxi
soderstrom has joined #linux-sunxi
<MoeIcenowy>
bbrezillon: I'm not referencing at all...
<MoeIcenowy>
This error occured at the line with content "deasserted before they can enter working state. This commit added the reset"
cptG has quit [Ping timeout: 258 seconds]
zuikis has quit [Ping timeout: 246 seconds]
<bbrezillon>
MoeIcenowy: it's probably matching on the 'commit' word
<bbrezillon>
MoeIcenowy: it that how you're waiting a bit before sending a new version
<bbrezillon>
I won't complain, but other maintainers might (5 versions in a single day is a lot)
zuikis has joined #linux-sunxi
<bbrezillon>
MoeIcenowy: BTW, it looks good now, I'll probably wait a bit before taking it though (just in case someone wants to review the patches)
jernej has quit [Ping timeout: 244 seconds]
vagrantc has joined #linux-sunxi
bonbons has quit [Ping timeout: 250 seconds]
<vagrantc>
apritzel: i tried following your instructions for using mainline u-boot, but the resulting image doesn't have serial console output https://github.com/apritzel/pine64/issues/7
<vagrantc>
apritzel: should the boot0.img from one of your previous firmware images work?
Andy-D has quit [Ping timeout: 264 seconds]
<vagrantc>
hmmm... ok, now i've got a working boot0.img ...
<vagrantc>
still hangs with "ERROR! NOT find the head of uboot."
<apritzel>
vagrantc: add "skip=1" to the last line and try flashing again
<apritzel>
that's a bug in those instructions
Andy-D has joined #linux-sunxi
<apritzel>
(just updated the comment)
bonbons has joined #linux-sunxi
<apritzel>
btw: I managed to net-install Debian, with the firmware image, the a64-v5 kernel and the official Debian netinst initrd
iaglium has joined #linux-sunxi
<longsleep>
apritzel: nice!
IgorPec has joined #linux-sunxi
<longsleep>
apritzel: so maybe next weekend i could think about a migration path from bsp
<longsleep>
apritzel: at least for those who want to run headless it should be good enough right?
<apritzel>
well, there are still issues (MMC seems slow, frequency is still at 816MHz, no audio)
<apritzel>
but yes, those are all fixable, just would love to see people jump on it
<apritzel>
I will probably push a new Linux image with the real Debian installer later
The_Loko has quit [Quit: Leaving]
<longsleep>
apritzel: any idea what could be a teaser for users? something what works with newer kernel but does not with BSP Kernel?
<KotCzarny>
samba/cifs?
<KotCzarny>
btrfs?
<longsleep>
samba/cifs works with BSP
<KotCzarny>
bugs galore?
<longsleep>
btrfs is outdated ok
<KotCzarny>
'works' he he
<longsleep>
but who cares if you can have zfs
<KotCzarny>
jrg recently was fighting samba in bsp
<KotCzarny>
so its painful (at least for him)
<longsleep>
huh - well maybe 3.10 lacks some features - i have just enabled it and people confirmed it works
<KotCzarny>
you mean pine bsp?
<longsleep>
yes
<KotCzarny>
he has h3 (3.4.x)
<longsleep>
ah
<longsleep>
sorry - no i mean pine64 bsp
<longsleep>
no clue about h3
<longsleep>
:)
<KotCzarny>
some driver that compiles with mainline and doesnt with 3.x ?
<longsleep>
pine64 bsp works pretty good including docker, lxd and kvm
<longsleep>
the only thing people requested and i could not enable is XFS
<longsleep>
but who really needs that
<longsleep>
zfs ..
<longsleep>
thats what i also answer when people ask about btrfs
<longsleep>
and even with mainline i am still not using btrfs in production - it has failed for me in the past and lost all trust
<longsleep>
it should be some killer which people really want to have, so they are willing to run a without any display support what so ever
<longsleep>
eg. board runs 50% faster :P
<KotCzarny>
irq balance?
<apritzel>
longsleep: 3 years worth of kernel development and fixes?
<apritzel>
errata workarounds?
<KotCzarny>
apritzel: most users are like this 'it works so what i get by upgrading?'
<longsleep>
yes - but thats all non features to end users
<KotCzarny>
longsleep, do some benchmarks maybe
<KotCzarny>
cpu, hdd/sd
<KotCzarny>
maybe usb devices
<longsleep>
apritzel: well there is no frequency scaling, so it will be slower for now
<KotCzarny>
network interfaces etc
<apritzel>
frankly: I don't care about "killer features", the BSP is not even a remote option for me
<longsleep>
apritzel: well yeah i understand that - i am looking for ways to make at least some users migrate as early as possible
<montjoie>
and now emac run faster with mainline:)
<longsleep>
i think ethernet could really be the key as many people claim that 1000M does not work for them with the BSP drivers
<longsleep>
no solution for that except forcing 100M
<xalius>
hi
<xalius>
Hi, am currently trying to learn how the battery charging part for the AXP803 PMIC on the Pine A64 is handled under Linux.
<NiteHawk>
isn't that an android issue? those running linux on the pine seem to complain far less
<longsleep>
so if that would just work with montjoie driver for those people then its a nice reason to use mainline
<KotCzarny>
does mainline kernel work with android from bsp?
<longsleep>
NiteHawk: yes they complain less because i have changed the settings for linux which seems to help in some cases
<NiteHawk>
longsleep: ah, okay.
<longsleep>
KotCzarny: i doubt anyone has tried or will try
<xalius>
longsleep: I tried to help a guy yesterday who had two identical 2GB Pine boards where on one the GbE was working fine, on the other it wasn't, he even used the same sdcard in both, same setup
<longsleep>
xalius: yes i know, i am out of ideas what could cause it
<xalius>
I was going over the schematics since I had trouble implementing GbE PHY in my owen hardware projects before
<longsleep>
xalius: and i already confirmed a non working board to work in my environment
<xalius>
and noticed that they account for different revisions of the RTL80211
<xalius>
but both of his and both of my boards all have a rev E PHY
<xalius>
my boards work fine
<longsleep>
xalius: its not the boards alone, its a combination of the board and the network
<xalius>
yeah I guess half of the problems come from interaction with other devices or just bad cables
<xalius>
I had one guy on IRC who just switched out the cables and then all was fine
<xalius>
I know from experience that GbE PHY are not trivial to implement so that they can hold up to the electrical specs in all conditions
<xalius>
especially with those cheap PCBs
<longsleep>
xalius: anyhow there is a problem in some situations and so far i am unable to reproduce or find a clue what it might be when one has two boards and one works while the other does not on the same switch port with same cable
<xalius>
yeah
<xalius>
can someone give me som pointers re the PMIC and how it is handled in Linux, I am usually a hardwar dev and only look at Linux drivers when I have to....
<longsleep>
xalius: well, pe patient and eventually someone might show up with that knowledge
<xalius>
ok
fredy has quit [Excess Flood]
<Amit_t_>
xalius: PMIC for pine64 ?
<xalius>
yes
fredy has joined #linux-sunxi
<Amit_t_>
I think its handle in ATF for pine64 not in Linux
<xalius>
As far as I can see there are some defaults for the battery charger registers in the device tree file and in the battery charger code in the kernel.
<xalius>
thanks I will look into that, maybe do some sniffing on the I2C bus to see if someone else is talking to the PMIC besides the Linux driver
<Amit_t_>
right now PMIC for PHY unit is happens through ATF
<xalius>
Amit_t_: the control of the regulators?
<Amit_t_>
I think yes
<xalius>
I measured some of the outputs on my boards and the settings from the device tree file seem to be whats in the regulator registers after booting Linux
<xalius>
wihtout image, it's just the register defaults of the PMIC itself
<apritzel>
xalius: I consider exposing the PMIC directly to be dangerous
<apritzel>
so I'd rather wrap the access by some interface
<apritzel>
like SCPI
<xalius>
I was surprised that Pine didnt state to only use their battery anywhere
<xalius>
looking at the defaults, they dont related to the battery sold with the Pine anyways
<apritzel>
xalius: in the Allwinner setup the arisc controls the PMIC, but there is an open interface using the messagebox device which is also wrapped by ATF
<xalius>
apritzel: that explains maybe why I only could make out parts of the functionality in the linux PMIC driver
<apritzel>
and I think the BSP U-Boot is the one actually setting up the proper PMIC values
<apritzel>
all the direct PMIC access is hidden in the arisc
<apritzel>
the rest (U-Boot, ATF and Linux) just use the messagebox interface
<xalius>
that is fine with me as long as I can understand what it is doing and lets me set the relevant parameters :)
<xalius>
thanks for the clarification
<apritzel>
My plan is to keep the PMIC controlled in ATF
<vagrantc>
apritzel: never really grasped dd's concept of skip vs. seek
<Da_Coynul>
testing sun8i-emac with Orange Pi PC on Arch Linux ARM
<Da_Coynul>
interface doesn't come up with systemd-networkd
<Da_Coynul>
also will not work with static connection set up manually
<montjoie>
any dmesg related to phy/emac ?
<vagrantc>
apritzel: very cool regarding debian-installer!
bonbons has joined #linux-sunxi
afaerber has joined #linux-sunxi
<Da_Coynul>
EMAC reset timeout
<montjoie>
Da_Coynul: which kernel do you use ?
<Da_Coynul>
hans' linux-sunxi wip-branch
<montjoie>
try mine
<Da_Coynul>
Thanks, will give it a try.
IgorPec has quit [Ping timeout: 276 seconds]
<willmore>
xalius, let me know if you need a tester. I have a big 8Ah Lipo that I want to hook to my Pine64.
<willmore>
It the size of the Pine64 board itself. :)
al1o has joined #linux-sunxi
<t00thless>
hi.. i've a small issue with compile kernel for lamobo-r1.. when I put zImage to a card on partition mmcblk0p1 and as a boot parametr i call for the zImage, than i get text Starting kernel and that's all.. nothing else.. can anyone help me to solve this out?
zuikis has left #linux-sunxi [#linux-sunxi]
<longsleep>
vagrantc: its simple, skip is for input and seek for output
Zliba has joined #linux-sunxi
staplr has joined #linux-sunxi
<Da_Coynul>
montjoie, with your kernel the link is down and I cannot bring it up at all
<Da_Coynul>
with hans' I could bring up the link (both LEDs on) but it would not work
<NiteHawk>
t00thless: which u-boot version are you using?
<Da_Coynul>
montjoie, I spoke too soon...unplugged and replugged ethernet cable and now looks like it's working
<t00thless>
from git
ricardocrudo has quit [Remote host closed the connection]
<NiteHawk>
and what is the linux kernel version that you built?
<t00thless>
NiteHawk, mainline from denx and kernel - i use vanilla kernel with patch for lamobo-r1 and grsec patch
<Da_Coynul>
monjoie, all good. Thanks for the tip.
<NiteHawk>
t00thless: okay. i was asking because there are some known issues / common pitfalls when booting older kernels with a recent mainline U-Boot. seems we can rule that out here. unfortunately that also means I have no real idea what might be going on. did you double-check that you provide a matching .dtb to the kernel?