Turl 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
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
bmeneg has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
doppo has quit [Read error: Connection reset by peer]
doppo has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.3]
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 240 seconds]
mosterta|2 has quit [Ping timeout: 258 seconds]
doppo has quit [Ping timeout: 260 seconds]
doppo has joined #linux-sunxi
doppo has quit [Remote host closed the connection]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
doppo has quit [Ping timeout: 260 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
doppo has quit [Ping timeout: 260 seconds]
doppo has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 272 seconds]
doppo has quit [Ping timeout: 264 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 272 seconds]
doppo has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 260 seconds]
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 272 seconds]
doppo has joined #linux-sunxi
<wens> that h3-based dvb set-top box looks interesting
<wens> if only i could find it on taobao
leio has quit [Ping timeout: 244 seconds]
doppo has quit [Ping timeout: 258 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 272 seconds]
doppo has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 250 seconds]
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
cnxsoft has joined #linux-sunxi
Zliba has quit [Ping timeout: 240 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 260 seconds]
Zliba has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 260 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
Zliba has quit [Ping timeout: 244 seconds]
doppo has quit [Ping timeout: 272 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 258 seconds]
doppo has joined #linux-sunxi
Zliba has joined #linux-sunxi
doppo has quit [Ping timeout: 264 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 258 seconds]
doppo has joined #linux-sunxi
doppo has quit [Ping timeout: 260 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
Zliba has quit [Ping timeout: 244 seconds]
vagrantc has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
doppo has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 260 seconds]
somedude23 has joined #linux-sunxi
orly_owl has joined #linux-sunxi
Zliba has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
lamer14662773957 has quit [Ping timeout: 246 seconds]
orly_owl has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
lamer14662773957 has joined #linux-sunxi
<MoeIcenowy> the battery driver for axp209?
<MoeIcenowy> bonbons seems to be not here...
vagrantc has quit [Quit: leaving]
<plaes> MoeIcenowy: nope, though parts of this have been included in another patches
lamer14662773957 has quit [Ping timeout: 260 seconds]
<MoeIcenowy> plaes: I just want to port something for batteries to axp22x...
<MoeIcenowy> although the usb power supply driver is already used by me
<MoeIcenowy> (for full otg
<MoeIcenowy> and I do think http://linux-sunxi.org/Linux_mainlining_effort is too sketchy
<wens> it's a wiki, you can always improve it
<MoeIcenowy> I don't dare to make big change.
JohnDoe_71Rus has joined #linux-sunxi
<KotCzarny> the worst tht could happen is reverse
<plaes> what's sketchy?
<MoeIcenowy> for example
<MoeIcenowy> lack of axp22x drivers
<plaes> AXP223 PMIC support
<plaes> AXP223 PMIC support was added in 4.6
<MoeIcenowy> plaes: only pek and regulator
<plaes> yeah, but there haven't been any patches for other parts
<MoeIcenowy> so they should be a task left to be done :-)
<MoeIcenowy> but usb power supply have now patch.
<plaes> yeah, but noone is working on those
<wens> axp223 usb power supply will be added in 4.8
<MoeIcenowy> wens: mainline 4.8 will support a31/23/33 full otg?
<plaes> I've been trying to update the list based on patches submitted, but sometimes I miss them
<MoeIcenowy> is it already "Planned for 4.8"
<MoeIcenowy> ?
<wens> depends on if all the musb and phy fixes got in
<wens> there's a whole lot of stuff from hans
<MoeIcenowy> wens: yes.
<plaes> yeah, it's somewhat hard for me to add Hans' patches there..
<plaes> ..mainly because they don't usually mention sunxi in the title
<plaes> axp223 usb supply is listed now
<MoeIcenowy> should A33/A64 audio codec be also a "left to be done" item?
<MoeIcenowy> if it should, I will add it
<wens> i doubt the "left to be done" list makes much sense
<wens> there's too much stuff to list
<MoeIcenowy> wens: thus... should we list it in the SoC's page?
<plaes> MoeIcenowy: who will maintain it?
<MoeIcenowy> plaes: If I have time, I will do it
<MoeIcenowy> but now I should prepare for my final exam.
<plaes> the supported feature matrix would be cool, though maintaining it is lots of work
<wens> agree
<KotCzarny> i think it should stay in mainlining page, and only link from soc page to relevant pieces to mainlining
<MoeIcenowy> matrix is a good idea
<MoeIcenowy> but will it be too gaint?
<MoeIcenowy> too many columns
<MoeIcenowy> (or let the SoC to be the columns, features to be the rows?
<KotCzarny> then make it transponded
<plaes> ok, AXPxxx bits and pieces added
<wens> the mainlining page is already scarcely maintained
<wens> u-boot page even less so
<MoeIcenowy> Maybe I should start to try to make such a feature matrix?
<plaes> yeah, it would be easier to maintain, if I would get all the patches in my inbox :)
<plaes> MoeIcenowy: go study for exam instead
<wens> plaes: you probably don't want that :p
<plaes> :D
<plaes> you would need to do work for A10, A10s, A13, A20, A23, A23s, A31, A33, A64, A80, A83T, H3, R8, .. and also for PMICs: A209, A223, ...
<plaes> hmm.. the only SoC with 's' prefix is A10s?
<MoeIcenowy> plaes: A31s
<wens> no A23s
<plaes> yeah, A23 should be A20s
<MoeIcenowy> maybe we should consider a sequence due to CPU core and IP cores...
<MoeIcenowy> (maybe my "due to" usage is not right :-)
<KotCzarny> h64?
<KotCzarny> ;)
<MoeIcenowy> for example, R8 should be listed next to A10s and A13
<plaes> it's too much work
<KotCzarny> make it for a20/h3 for a start, they are the most popular i think
<plaes> MoeIcenowy: did you try submitting the esp stuff to staging?
<MoeIcenowy> plaes: I cannot ensure their copyright.
<MoeIcenowy> they didn't come with any GPL header
<montjoie> make it with color like we speak some days ago
<MoeIcenowy> but come with "Copyright (c) 2010 -2014 Espressif System."
<plaes> didn't the guy behind SpritesMods work there?
<MoeIcenowy> we cannot prove they're not leaked code (seems that they're just leaked code)
<plaes> I would still submit it, maybe someone in that list knows someone in espressif
<MoeIcenowy> and I cannot promise the code style is suitable to be mainlined
<MoeIcenowy> although I did indent -kr -i8
<MoeIcenowy> Chinese manufacturers always provide sh*tty code
<plaes> well, just take a look at the realtek stuff there
<montjoie> MoeIcenowy: If you want to do the matrix, usually I take https://nouveau.freedesktop.org/wiki/FeatureMatrix/ as example
<MoeIcenowy> plaes: it's different on license
<MoeIcenowy> the realtek driver is based on the driver available on the Realtek's website
<MoeIcenowy> but the esp8089 driver is extracted from the leaked sdk of rockchip
<MoeIcenowy> (although the LICENSE file in linux-rockchip is GPL
<wens> MoeIcenowy: staging is ok with code style issues i think
<wens> damn... the ac100-rtc driver uses so many rsb transfers
<MoeIcenowy> wens: thus I should try to make a driver to put it into drivers/staging/esp8089 ?
<wens> everytime i run hwclock, the interrupt count goes up by 10k...
<MoeIcenowy> (and this driver is only for the sdio variant
<MoeIcenowy> (the spi variant's support is dropped in my code
<plaes> MoeIcenowy: we don't care for now :)
<MoeIcenowy> plaes: right
<MoeIcenowy> (but it seems that some people made esp8089 wifi kits on rpi with spi
<plaes> yeah
<plaes> btw, did you have some timing issues when starting up the esp8089?
<MoeIcenowy> plaes: timing?
<plaes> Hans added the delay parameter for power supply
<plaes> see those two patches:
<MoeIcenowy> plaes: the main problem of esp8089 is not timing issue
Amit_t_ has quit [Ping timeout: 250 seconds]
<MoeIcenowy> the card need a restart after the firmware is loaded
<MoeIcenowy> so I used "broken-cd" instead of "non-removable" in the dt
<MoeIcenowy> otherwise the probe in the second time will fail
<plaes> ok, thanks, I mixed those two issues up
<wens> looking at other sdio based controllers, the sdio backplane function have a "reset card" command
lamer14662773957 has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
p1u3sch1 has quit [Quit: ZNC - http://znc.in]
<MoeIcenowy> plaes: is sending a patch with all driver files suitable?
p1u3sch1 has joined #linux-sunxi
<plaes> you can try..
<plaes> but you need to send your patch against staging-next
<MoeIcenowy> staging-next?
<MoeIcenowy> not master?
<MoeIcenowy> what the hell
<MoeIcenowy> so many git repos
<plaes> gregkh handles staging tree
mossroy has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
<plaes> git remote add gregkh-test git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/linux.git
<plaes> duh.. wrong terminal :)
<plaes> should be: git remote add gregkh-test git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
<MoeIcenowy> added it
<MoeIcenowy> and checked out it
mosterta|2 has joined #linux-sunxi
<plaes> ok, worked through some of the applied patches..
<MoeIcenowy> plaes: should I contain "Signed-off-by: Icenowy Zheng <...>" in the commit message?
<plaes> yes
<plaes> git commit -a --amend -s
<plaes> it adds automatically
<plaes> could you add me to CC (plaes @ plaes.org )
Netlynx has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
lamer14663254420 has joined #linux-sunxi
lamer14662773957 has quit [Ping timeout: 260 seconds]
fredy has quit [Excess Flood]
bonbons has joined #linux-sunxi
fredy has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
lamer14663266255 has joined #linux-sunxi
lamer14663254420 has quit [Ping timeout: 260 seconds]
al1o has joined #linux-sunxi
<KotCzarny> bonbons: MoeIcenowy was looking for you
<bonbons> KotCzarny: when/context?
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<KotCzarny> 08:53 #linux-sunxi MoeIcenowy> have anyone used http://lists.infradead.
<KotCzarny> org/pipermail/linux-arm-kernel/2014-October/295547.html ?
<KotCzarny> 08:53 #linux-sunxi MoeIcenowy> the battery driver for axp209?
<KotCzarny> 08:54 #linux-sunxi MoeIcenowy> bonbons seems to be not here...
<bonbons> thanks!
jernej has joined #linux-sunxi
<MoeIcenowy> plaes: where should I send the staging driver?
leilei has joined #linux-sunxi
<plaes> MoeIcenowy: see whether /scripts/get_maintainer.pl gives anything for your patch
ricardocrudo has joined #linux-sunxi
apritzel has joined #linux-sunxi
bfree has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
lamer14663303348 has joined #linux-sunxi
lamer14663266255 has quit [Read error: Connection reset by peer]
The_Loko has joined #linux-sunxi
lamer14663303348 has quit [Ping timeout: 252 seconds]
fdcx has quit [Ping timeout: 264 seconds]
fdcx has joined #linux-sunxi
<MoeIcenowy> plaes: should staging driver be sent at linux-kernel@vger.kernel.org
<MoeIcenowy> or devel@driverdev.osuosl.org ?
<MoeIcenowy> the perl script tell me the two lists
<MoeIcenowy> and tagged the latter one as "STAGING SUBSYSTEM"
leio has joined #linux-sunxi
nove has joined #linux-sunxi
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
<agraf> MoeIcenowy: if it tells you multiple lists, always send it to all of them
<MoeIcenowy> agraf: thx!
<plaes> yeah
<MoeIcenowy> I get a failure email for sending to linux-kernel@vger.kernel.org ...
<plaes> o_O
lemonzest has joined #linux-sunxi
<plaes> looks correct
<MoeIcenowy> maybe I should change a mail address?
<MoeIcenowy> I cannot also send to majordomo@vger.kernel.org to subscribe...
<MoeIcenowy> if I want to send a patch, should *ALL* the mail addresses returned by get_maintainer.pl be sent?
<MoeIcenowy> be sent to
<plaes> yes
<plaes> there could be size issue
<MoeIcenowy> MoeIcenowy: size issue?
<MoeIcenowy> my subscribe email have only one sentence!
<MoeIcenowy> "subscribe linux-kernel"
Netlynx has quit [Quit: Leaving]
<MoeIcenowy> should I resend it with another email address?
<plaes> MoeIcenowy: email too big
<plaes> what's inside the error email?
<MoeIcenowy> Delivery to the following recipients failed.
<MoeIcenowy> I have now also two patches for sunxi-nand (A31+ nand reset line support) to send.
<plaes> ok, try with those first then :)
<MoeIcenowy> maybe I should use another mail?
<plaes> dunno
<MoeIcenowy> (use my open-source-community or school mail maybe better than outlook.com...
<MoeIcenowy> as my mail to subscribe the list is also failure...
<KotCzarny> pastebin whole error
<MoeIcenowy> http://pastebin.com/CPtpMARD so meaningless
<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.
<KotCzarny> you might try docs for http://linux-sunxi.org/AXP209
<xalius> I was planning to use custom batteries with my Pine and need to be able to set / get register access to the AXP803.
<KotCzarny> 803 might be similar
<jelle> hmm I wonder does A33 already display the remaining battery?
<xalius> we luckily have the datasheet for the 803 so I know how it operates
<jelle> or support it
<xalius> I was just looking for info how/if one can control the aspects of the battery charger part from userpsace
<xalius> or if more work on the driver is needed
<KotCzarny> xalius, i bet on doing some ioctl/memset, as the chips is selfcontained
<xalius> there is also a proprietary bus protocol mention that indicates the PMIC could be in part controlled by a low level MCU embedded in the SoC
<xalius> Is there a use-case I could look at from other sunxi devices with battery chargers in their PMIC?
<KotCzarny> im just an user, and only using battery as a poor man's ups in lamobo-r1
<KotCzarny> there are some toggles in /sys/
<KotCzarny> and some in .fex and basically that's it
<xalius> Allwinner seems to have implemented parts of a statemachine in the PMIC driver for the charging that seems to handle most things
<longsleep> xalius: i guess you should look at the atf and arisc, the latter one controls the power
<xalius> also in the A64, that is news to me, thanks
<xalius> so there is a sub-core embedded that runs management code?
<longsleep> xalius: afaik the arisc firmare is not availbe as source (embedded in u-boot as scp.bin)
<longsleep> xalius: yes - apritzel hat some docs from the early a64 days
<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
<Amit_t_> arm-trusted-firmware/plat/sun50iw1p1/sunxi_power.c
<xalius> thanks
<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
<apritzel> this sets up the RSB controller and programs some bits in the PMIC (DC1SW, DCDC1 voltage)
<xalius> I will have a look
<xalius> so the ATF in an image is something we can actually build from source?
<longsleep> xalius: yes, its part of the base firmware, for BSP its bundled together with U-Boot
<xalius> ok
<longsleep> xalius: i have a branch for BSP compatibility at https://github.com/longsleep/arm-trusted-firmware
<longsleep> xalius: my build gear includes instructions how to build and combine it with U-Boot
<longsleep> xalius: if you use mainline, use apritzel's https://github.com/apritzel/arm-trusted-firmware/tree/allwinner branch
<xalius> ok thanks
<xalius> guess I got a lot of reading to now ;)
ninolein has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
jukivil1 has joined #linux-sunxi
lastebil has joined #linux-sunxi
jernej has joined #linux-sunxi
staplr has quit [Ping timeout: 260 seconds]
xenoxaos- has joined #linux-sunxi
bonbons has quit [*.net *.split]
ninolein_ has quit [*.net *.split]
afaerber has quit [*.net *.split]
Net147 has quit [*.net *.split]
Jasu_ has quit [*.net *.split]
lastebil_ has quit [*.net *.split]
xenoxaos has quit [*.net *.split]
jukivili has quit [*.net *.split]
xenoxaos- is now known as xenoxaos
Net147_ has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Jasu has joined #linux-sunxi
<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> "mainline" from denx.de or the "legacy" https://github.com/linux-sunxi/u-boot-sunxi?
<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?
<NiteHawk> it's also advisable to have http://linux-sunxi.org/Mainline_Kernel_Howto#Early_printk enabled - it might help diagnosing kernel startup problems
jstein_ has joined #linux-sunxi
jstein_ has quit [Client Quit]
jstein_ has joined #linux-sunxi
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
jstein_ has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
jstein_ has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mossroy has quit [Quit: Quitte]
jstein_ has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
jstein_ has joined #linux-sunxi
nove has quit [Quit: nove]
pmattern has joined #linux-sunxi
somedude23 has quit [Quit: Ex-Chat]
<apritzel> vagrantc: skip vs. seek is quite simple: skip is for the input file (if=), seek is for the output file (of=)
<apritzel> now you just need to remember which is for which ;-)
<vagrantc> dd if=pine64.img of=/dev/sdx bs=8k seek=1 skip=1
<apritzel> yes
<vagrantc> wouldn't that only install part of the image?
<vagrantc> i guess the only part that matters...
<apritzel> it skips the first 8KB both in the source and the target
<apritzel> if you look at pine64.img with a hex editor, you will see that the first 8KB are zeroes
reinforce has quit [Quit: Leaving.]
<vagrantc> at any rate, i still was getting the error with u-boot
* vagrantc understood skip vs. seek conceptually, just always forgets which to use
soderstrom has quit [Quit: leaving]
<vagrantc> "sdcard 0 init ok
<vagrantc> ERROR! NOT find the head of uboot."
<camh> vagrantc: skip has an I in it, so it's for input
staplr has quit [Ping timeout: 244 seconds]
<vagrantc> i guess i'm not strictly using mainline u-boot, i'm using v2016.07-rc1
<apritzel> vagrantc: weird, can you check out the more elaborate instructions here: https://gist.github.com/apritzel/68941c29c77955f1daa45b50d36c5425
<apritzel> vagrantc: aha!
<apritzel> then you need the one patch the prefixes U-Boot with the boot0 header
<vagrantc> apritzel: i didn't see any obvious patches since rc1 ... but ok.
<apritzel> oh wait
<apritzel> rc1
<apritzel> ah, no, the patch is in -rc1
<vagrantc> cdaa633fcf9c2bd54aa3c130ee727708a4e2406a ?
<apritzel> yes, it's -rc1~3
<apritzel> vagrantc: can you be my beta tester for the instructions I posted above?
<apritzel> I briefly tested it yesterday and it worked for me
<vagrantc> i can give it a quick try, but probably need to work on some other things for the coming weeks
<apritzel> vagrantc: where did you get the boot0.img from?
<apritzel> from my latest firmware image?
<vagrantc> apritzel: yeah
<apritzel> ah, this one has a patched boot0
<apritzel> which reads U-Boot from 40KB and not 19096KB
<vagrantc> 20160601.img
<vagrantc> aha
<apritzel> my newest boot0img takes care of that
<apritzel> (but I haven't pushed it yet)
<apritzel> you could try use an older image (for instance the Linux one) to get boot0.img
<apritzel> sorry for that, that new firmware image was a bit of a sneak peek into the boot0 hack
<vagrantc> well, i'm well aware that pine64 support is pretty much under development :)
<apritzel> so basically any image _except_ my latest firmware image is good for harvesting boot0 ;-)
<vagrantc> and happy someone is doing the work
* vagrantc reharvests
<apritzel> my new boot0img version can deal with both
<vagrantc> if i disappeared for three weeks, would everything just magically work? :)
* vagrantc wonders if it would be feasible/useful to get arm-trusted-firmware into debian
jernej has quit [Quit: Konversation terminated!]
<longsleep> apritzel: how did you patch boot0? rebuilt it from BSP?
jstein_ has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<longsleep> apritzel: btw you could point to https://github.com/longsleep/build-pine64-image/blob/master/blobs/boot0.bin in your instructions
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<vagrantc> apritzel: ok, made it as far as u-boot v2016.07-rc1 :)
<vagrantc> apritzel: is it feasible to write the u-boot.bin to a specific offset, or does boot0img have to do some magic mangling for it to work?
<vagrantc> (presuming all the other bits are in the right places)
<apritzel> yes, writing it to 19096KB works with the old boot0
<apritzel> but you need to patch in ATF and the arisc
<vagrantc> apritzel: the longer instructions definitely are nice :)
<apritzel> also ajdust the checksum
<apritzel> and and and ... that's why you have boot0img ;-)
<vagrantc> right
<vagrantc> the short answer is basically "no" the long answer is "if you really want to..."
al1o has joined #linux-sunxi
<apritzel> kind of
<apritzel> I did the manual patching for some weeks, then got annoyed by all the booby traps
<apritzel> also found it hard to communicate the process over IRC ;-)
<vagrantc> with things that are error-prone, a tool is generally a better idea
<vagrantc> and it boots!
<vagrantc> well, that's good enough for debian experimental
<apritzel> I used to copy the checksum from the boot0 output and hack it in with: "echo 0 12 34 56 67" | xxd -r | dd of=/dev/sdx bs=4 seek=4888579
<apritzel> at this point I decided to write the tool ;-)
<apritzel> vagrantc: great!
* vagrantc thanks apritzel for great wisdom and skill
* apritzel blushes
<xalius> is there a way to disable HDCP on the HDMI through the display engine driver from userspace or by configuration at boot?
<apritzel> montjoie: very impressive work on your driver! Just saw the fixes in your new branch
<agraf> apritzel: you surely mean 67 56 45 12 ;)
<apritzel> agraf: in this example boot0 reported 0x67563412, of course ;-)
<agraf> apritzel: heh :)
<longsleep> xalius: HDCP is disabled
<vagrantc> apritzel: now i'll nudge you to get a README.pine64 into upstream u-boot ... it looks like you have useable text already :)
Gerwin_J has joined #linux-sunxi
<agraf> vagrantc: that text wouldn't stay valid for long
<apritzel> indeed
<agraf> vagrantc: the plan is to use U-Boot's native SPL
<vagrantc> even better! :)
<agraf> vagrantc: at that point everything in the readme becomes obsolete
<agraf> apritzel: btw, any idea about my HYP problem? :)
<xalius> longsleep: thank you that was what I was looking for, although it doesnt explain my problems with non-HDCP display :)
<apritzel> I plan to submit a more generic README, which points to these instruction in my github
<apritzel> agraf: which one? (seem to have missed that ...)
<agraf> apritzel: let's move that to #kvm-arm :)
bonbons has quit [Quit: Leaving]
staplr has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
al1o has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
<vagrantc> apritzel: no ethernet found from u-boot is expected?
staplr has quit [Remote host closed the connection]
<vagrantc> and no usb?
<apritzel> vagrantc: yes, at the moment both are WIP
<apritzel> though there are some patches floating around already
<apritzel> and kernels have been loaded via TFTP and from an USB pen drive already
<vagrantc> nice
jstein_ has joined #linux-sunxi
jstein_ has quit [Client Quit]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
Shirasaka-Hazumi has quit [Ping timeout: 276 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
lemonzest has quit [Quit: Leaving]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gzamboni has quit [Read error: No route to host]
<Zliba> is it morally ethical to kill a cat for intentionally spilling a glass of water which ended up on a board?
<Zliba> i've killed a cat before, but not MY cat, so i'm wondering
<orly_owl> allow me to introduce you to the motto of every cat: you set em up, we knock em down
<orly_owl> Zliba: put your damn drink away from your work area
<Zliba> orly_owl, i have a huge desk... the cat had no right to knock over the cup
<Zliba> and it keeps climbing me to get on the desk. claws hurt.
<orly_owl> put your drink on the floor
<Zliba> orly_owl, i have persian rugs on the floor and they use vegetable dyes that can run with water
<orly_owl> begin a diet of dry foods only
<Zliba> or.... kill the cat
<Zliba> or put it outside and let other creatures kill it
<MoeIcenowy> strange problem here...
<orly_owl> not to mention off topic
xalius has quit [Quit: Page closed]
Da_Coynul has joined #linux-sunxi
<apritzel> indeed: $ cat sunxi => cat: sunxi: No such file or directory
<buZz> you know what always disappoints me
<buZz> there is such lack of videos of people throwing cats at other people out of selfdefense
fredy has quit [Excess Flood]
<MoeIcenowy> apritzel: :-)
fredy has joined #linux-sunxi
xalius has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]