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
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 250 seconds]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ricardocrudo has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
<apritzel> longsleep: I pushed quite some patches to my ATF repository on github
<apritzel> the original commits are still there, but I am afraid you have to pick another HEAD for your BSP kernel stuff
<apritzel> or you take this opportunity and join us in the shiny upstream world, where we have a proper, upstream 64-bit U-Boot and now also Ethernet support in the kernel
boobypi has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<boobypi> montjoie: I trying your EMAC driver with linux4.6 uboot2016-05 and it's great. Only little bug i see, i must plug an ethernet cable at startup if not : Could not attach to PHY. Thanks a lot
<boobypi> Openwrt (linux4.6.1 stable with usb reset patch) H3 work fine with your Emac driver - ssh, http, dns, iperf > 90Mbit in both dirrection :)
boobypi has quit [Quit: Page closed]
ricardocrudo has quit [Remote host closed the connection]
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
<vagrantc> well, managed to get a patched linux 4.6 on the pine64 to at least partially boot ... but it seems to crash before the initramfs is even loaded.
cnxsoft has joined #linux-sunxi
* vagrantc wonders which of apritzel's branches is the most complete
<wens> mripard: yay for i2s!
<luoyi> how can I use git format-patch to reply a ongoing review mail ?
reev has joined #linux-sunxi
<wens> if it's a new revision, just send it. No need to chain it to the old thread
<wens> it might get missed if you do
Nacho_ has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
<plaes> luoyi: --in-reply-to=Message-Id
IgorPec has joined #linux-sunxi
bmeneg has quit [Ping timeout: 264 seconds]
solarnetone has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
solarnetone has joined #linux-sunxi
bmeneg has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<wens> bpi-m3 emmc is also empty, but written with ascending ascii table
JohnDoe_71Rus has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
pzabielo_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
pzabielo_ has quit [Client Quit]
pzabielo has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 258 seconds]
iamfrankenstein1 is now known as iamfrankenstein
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 258 seconds]
Akagi201 has joined #linux-sunxi
WB6ALX has quit [Ping timeout: 272 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
MrBIOS-DT has joined #linux-sunxi
phipli has joined #linux-sunxi
IgorPec has joined #linux-sunxi
phipli has quit [Ping timeout: 260 seconds]
Akagi201 has quit [Read error: Connection reset by peer]
Akagi201 has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein has joined #linux-sunxi
clonak has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
pietrushnic is now known as pietrushnic`away
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
kaspter has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
<apritzel> vagrantc: in case you read this: a64-v5 is the most recent, this includes working Ethernet support
<agraf> apritzel: so how much is missing upstream? :)
alain has joined #linux-sunxi
<alain> montjoie: just tested your latest sun8i-emac driver, it works, however compared to wens' driver it takes more time to initialise and creates issues with systemd at boot time.
<KotCzarny> 'creates issues with systemd' isnt that a good thing?
<apritzel> agraf: on what front? Kernel, u-boot, ATF? ;-)
* KotCzarny grins
<alain> hahah
<NiteHawk> apritzel: does that need a special ATF or u-boot in order to work (for the RSB setup of the PMIC)?
<apritzel> NiteHawk: yes
<agraf> apritzel: kernel
<apritzel> NiteHawk: and (drumroll ...) I even managed to push it last night
<NiteHawk> \o/
<NiteHawk> :D
<apritzel> agraf: well, the a64-v5 branch is on top of 4.7-rc1
<apritzel> the point is:
<apritzel> I am afraid this one clock patch will never be merged
<apritzel> so I am thinking about a bigger change, which would make our work in the future much easier
<apritzel> ditching sunxi clocks at all and moving to firmware controlled clocks
<apritzel> using SCPI and implementing the clock register setup in ATF
<apritzel> SCPI clocks are already in the kernel, so we get this part for free
<apritzel> all we need kernel wise is a simple mailbox driver
<alain> now that I've switched my OPI Plus to mainline I see quite a few errors related to my external usb drive. http://pastebin.com/raw/N15EKZpC Anything worrying? I would understand it is just trying UAS...
<agraf> apritzel: why do we need a new mailbox driver?
<apritzel> agraf: for the SCPI communication
<apritzel> that binding relies on mailboxes and shared memory
<apritzel> because it's meant to communicate with a service processor
<agraf> apritzel: ah, ok
<agraf> apritzel: i see
<apritzel> but I reckon we can do this in EL3 on the ARM cores as well
<apritzel> the driver shouldn't be complicated
<apritzel> it just needs to be done
<apritzel> the good thing is: from that point on the kernel is ready
<apritzel> all we need are the proper DT nodes and the firmware side
<apritzel> btw: Allwinner calls it "message box"
<agraf> so i suppose there's no standardized PSCI interface for clock control?
<agraf> maybe we could do a PSCI-SCPI-tunnel-mailbox driver?
<agraf> it could easily be synchronous, right?
<agraf> then properly define it in the PSCI spec and thus allow everyone to use it
<apritzel> SCPI is what you are looking for
<apritzel> well, we could go this way
<NiteHawk> apritzel: so what's needed to join shiny upstream? kernel is clear to me (a64-v5 on top of 4.7-rc1), judging from your commits i suspect the "allwinner" branch of arm-trusted-firmware, and which u-boot?
<apritzel> NiteHawk: latest upstream plus the one patch the Steve Rae posted to have the boot0 header
<agraf> it'd just be nice to ensure that we won't end up with 5 different drivers for this on different platforms ;)
<apritzel> agraf: the point is: this would add out-of-standard interface changes
<NiteHawk> oh. is that in u-boot-sunxi.next already?
<apritzel> NiteHawk: it's currently bikeshed^Wdiscussed on the ML
<NiteHawk> okay :D
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<montjoie> alain: which exact branch do you use from wens and I (could you diff the sun8i-emac.c on pastebin ?)
<mripard> apritzel: come on, I rewrote a whole clock framework so that you wouldn't have to...
kaspter has joined #linux-sunxi
<apritzel> mripard: I saw that, and the idea is nice
<mripard> saying "I won't upstream my patch because of that clock driver" is just bad faith
<alain> montjoie: yours is sun8i-emac-wip and wens is bpi-m2p-emac
<apritzel> mripard: well, the last reactions to that patch were pretty clear
<apritzel> mripard: and I am trying to write a comment to your series for days now ...
<apritzel> it's still super complicated
<apritzel> (for everyone not sleeping with an Allwinner manual under the pillow for years)
IgorPec has joined #linux-sunxi
<apritzel> and: we need a huge file for each and every SoC
<apritzel> I don't see if we could share this
<mripard> you know how I feel about any ARM architecture stuff now
<alain> montjoie: here's the diff http://pastebin.com/5bz6N3KC
<mripard> it doesn't mean that I shouldn't use it
<apritzel> mripard: after all my approach is independent from your rewrite
<mripard> no it's not
<apritzel> which is needed for every platform that cannot easily have proper firmware
<mripard> because then, you blame it on me for not having upstream support
<montjoie> alain so nothing that explain a change
<montjoie> alain: what is the issue with systemd ?
<apritzel> mripard: I didn't blame you, sorry if you got this impression
<apritzel> mripard: what I wanted to ask you: do we actually do any kind of clock reparenting in real life?
<mripard> for some clocks, yes
<apritzel> can't we go with a static clock setup for the basic clocks (APB, AHB), which Allwinner recommends anyway?
<mripard> we already had that discussion
<KotCzarny> :)
<mripard> we can do it for APB / AHB
<mripard> but we can't for all the other clocks
<mripard> which means that we need to have the logic to deal with several parents
<mripard> and if we have the logic to deal with it already
<mripard> why should we take a shortcut?
<alain> montjoie: times out waiting for the eth0 interface to come up and drops me into emergency mode, by then the interface has had the time to come up and works fine.
<apritzel> mripard: regarding sunxi-ng: I wanted to bit the bullet the other day and create an A64 clock driver
<alain> montjoie: rebooting on wens' kernel solves the issue
<apritzel> but was shocked by the amount of code that I need to add
<apritzel> actually: not code, but data
<apritzel> can't we share this
<apritzel> it's 95% H3 clocks, really
<wens> for a monolithic block, probably not
Michal has quit [Ping timeout: 244 seconds]
<wens> alain: sounds weird
<alain> wens: I know, tried twice to rule out some other issue
<alain> wens: let me try another time
<apritzel> mripard: I will try to send an email explaining my arguments later
<apritzel> ($work ahead)
<wens> alain: only difference i see that makes a difference are the rgmii pins, mine has 2 pins less
<alain> wens: going at it a 3rd time, same issue. With your kernel I get a clean boot, with montjoie's systemd times out on [ OK ] Found device /sys/subsystem/net/devices/eth0.
<montjoie> wens: seems that I need to remove thoses pins:)
<mripard> apritzel: it's data you would have needed in the DT anyway
<mripard> and data you'll need in the firmware too
<alain> another issue I noticed but need to investigate further, I left the board running overnight with wens' kernel and this morning network was not working, as simple ifdown / ifup restored connectivity. May be unrelated as I rebooted the network switch in the meantime.
<wens> you could also look at allwinner's clock driver... not pretty either
<mripard> apritzel: we can probably come up with some way to share most of the clocks
Michal has joined #linux-sunxi
libv_ has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
<wens> mripard: not hard coding hw.init would probably cut down on redundant structures?
<wens> (but probably introduce new ones for init time
Akagi201 has joined #linux-sunxi
Michal has quit [Changing host]
Michal has joined #linux-sunxi
<mripard> wens: you still have to provide what's inside
<mripard> wens: and mike wants to add a new API to register a clock by it's parent clk_hw
<mripard> so it has to be static
libv has quit [Ping timeout: 272 seconds]
<wens> i doubt name based parenting will ever disappear though
<wens> we have the stupid CCU <-> PRCM dependency, where osc24M and osc32k are from PRCM, but PRCM also wants pll_periph
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
pzabielo_ has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 240 seconds]
Mr__Anderson has quit [Remote host closed the connection]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
alain has quit [Quit: Page closed]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
libv has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
libv_ has quit [Ping timeout: 272 seconds]
libv_ has joined #linux-sunxi
<jrg> my opi+2e made it to nyc!
libv has quit [Ping timeout: 246 seconds]
pekka10 has quit [Quit: WeeChat 1.2]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
tkaiser has joined #linux-sunxi
<tkaiser> Huh? BPi M2+ fails at 624 MHz clockspeed when trying out lima-memtester :( Currently testing 600 MHz
<KotCzarny> :>
<tkaiser> At least I got spinning cubes today. Already tested OPi Lite and PC Plus
iamfrankenstein has quit [Ping timeout: 258 seconds]
pietrushnic has quit [Ping timeout: 250 seconds]
<wens> tkaiser: huh? that bad?
<wens> was about to submit mainline u-boot patches
<wens> guess i'll wait for your results
<tkaiser> wens: I'm a bit shocked too. Borrowed already a powermeter from a neighbor since BPi M2+ can also be powered through the OTG port unlike Oranges. And I feared that I run in underpower situations when testing through FEL mode. But that's not the case, the board uses DC-IN (using Xunlong's 3A PSUs for OPi Plus 2E)
<tkaiser> I try to encourage other M2+ users to test too in the meantime. Wouldn't be the first time that my boards behave somewhat strange
Mr__Anderson has quit [Remote host closed the connection]
Mr__Anderson has joined #linux-sunxi
pietrushnic has joined #linux-sunxi
<ssvb> tkaiser: don't forget that U-Boot uses some hardcoded Orange Pi DRAM settings
Akagi201 has quit [Remote host closed the connection]
<ssvb> tkaiser: the banana may probably need its own tuning
<ssvb> tkaiser: have you compared the [dram_para] section in the banana and orange fex files?
<tkaiser> ssvb: Good point, I'll have a look and compare dram settings in fex files.
<wens> fex files for bpi-m2+
<tkaiser> wens: I know, I spotted it before M2+ was ready there. And dram_para section is identical to the Xunlong used for Orange Pi PC.
alain has joined #linux-sunxi
<alain> So I keep getting these messages every 30 minutes since switching to mainline kernel. Any ideas? http://pastebin.com/raw/vp1WkxYg
reev has quit [Ping timeout: 272 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
<tkaiser> wens: Are you able to ask Foxconn questions? Eg whether they did just copy&paste from the fex they found inside loboris kernel sources or tried to develop own settings for their board?
<ssvb> tkaiser: maybe they just don't have much clue about both the hardware and software...
<tkaiser> ssvb: Given the experiences made with them in the past I would say 'yes'. But that's also a bit unfair...
<ssvb> tkaiser: was it you who mentioned that the original banana pi board had been actually designed by Xunlong people?
IgorPec has joined #linux-sunxi
<tkaiser> ssvb: That was Steven's claim and wens said the same yesterday or the day before after talking to Foxconn people.
<tkaiser> Steven/Xunlong did the ODM design, then SinoVoip took over to manufacture and LeMaker were the agent in the beginning. Anyway regarding fex files we had no luck with R1 and M2 but all that happened a while ago.
<ssvb> tkaiser: why do we even care about these banana boards?
<ssvb> maybe it's best to advise the users to just stay away from them?
<tkaiser> ssvb: Hmm... the A20 based boards are fine. Everything that came later has been somewhat... crappy?
<tkaiser> My BPi M2+ seems to run stable at 600 MHz with these settings. But since there is a 2nd led missing on this board I let it run for a few hours more
Mr__Anderson has quit [Ping timeout: 260 seconds]
<ssvb> tkaiser: maybe I need to update the test to also take the boards with only one LED into account
Mr__Anderson has joined #linux-sunxi
<ssvb> there is still the CHIP board, which maybe will reach me eventually
<ssvb> it also has only a single LED, so the lima-memtester test will need some updates if we want to check DRAM reliability on CHIP too :-)
libv_ has joined #linux-sunxi
<ssvb> tkaiser: just pay attention to the spinning cube, if it is running with the gray background then everything is fine :-)
<tkaiser> ssvb: The other Orange Pi clone from FriendlyARM uses two leds (blue instead of red but identical pin mapping) so it's just BPi M2+ when we're talking about H3 boards. And I'm more concerned regarding the problems we have on OPi Plus 2E than CHIP ;)
<ssvb> tkaiser: I'll get the board and will look into them
<tkaiser> ssvb: Yes, learned the lesson and rely on the spinning cube with purple background (DVI display and therefore wrong color mode used by H3 for whatever reasons)
<ssvb> tkaiser: be careful, a glowing red background means that problems had been found
libv has quit [Ping timeout: 244 seconds]
<tkaiser> ssvb: Ok, changed color mode from RGB to YPbPr to confirm background is gray.
Nacho has quit [Remote host closed the connection]
<tkaiser> But the more I think about the more I come to the conclusion that this board isn't worth the efforts. OPi Plus 2E has also GbE, one more useable USB host port, twice the DRAM, twice the eMMC size (also faster), the way better voltage regulator and a PCB showing really good heat dissipation allowing way higher clockspeeds...
<tkaiser> (should I continue? ;)
Nacho has joined #linux-sunxi
<ssvb> well, competition is still good for keeping the prices low :-)
<tkaiser> Major drawback: OPi Plus 2E costs $3 more compared to BPi M2+! ;) After including shipping costs it's the other way around of course
iamfrankenstein has joined #linux-sunxi
libv has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
pzabielo has quit [Quit: Ex-Chat]
pzabielo_ has quit [Remote host closed the connection]
<wens> tkaiser: shipping is different for people around the world :p
libv_ has quit [Ping timeout: 240 seconds]
<tkaiser> ssvb: How long should lima-memtester run at least? Just writing a mini tutorial how to use it with BPi M2+
libv_ has joined #linux-sunxi
<ssvb> tkaiser: some information is available here - https://linux-sunxi.org/Hardware_Reliability_Tests#Reliability
<ssvb> tkaiser: an overnight run is the best, but just an hour or two is also ok
libv has quit [Ping timeout: 264 seconds]
<tkaiser> ssvb: I wrote '1 hour' in the instructions and will ask testers to run their last stable clockspeed over night _if_ someone gets back to us. http://forum.armbian.com/index.php/topic/1322-testers-wanted-testing-dram-reliability-on-bpi-m2/
<tkaiser> Will now write messages to the few users that have a BPi M2+ and are exprienced enough to run lima-memtester.
libv has joined #linux-sunxi
<tkaiser> wens: I hope some users will test and get back with feedback. Since I tortured my BPi M2+ more or less by accident (5 days in a small cardboard box running cpuburn-a7) I don't trust that much into my personal lima-memtester results. But maybe the problem is really just copy&paste from Xunlong fex file and therefore wrong DRAM calibration 'by design'
<tkaiser> 'Team BPi' has also no clue about thermal issues. With their original fex file, BPi M2+ clocks with 1008 MHz max and kills CPU cores pretty soon. I reported this to them a few weeks ago but as usual they do not care.
libv_ has quit [Ping timeout: 264 seconds]
Akagi201 has joined #linux-sunxi
alain has quit [Ping timeout: 250 seconds]
al1o has joined #linux-sunxi
lemonzest has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<jrg> 2 more months of blockchain to go for the bananapi
<montjoie> alain could you apply https://github.com/wens/linux/commit/4284edeacad86d657c7f07cd22b7051c04ed8dfb on my branch and retest ?
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
<TheLinuxBug> ssvb: any idea when we will actually be receiving chip, I ordered one and of course they say "June" but I was wondering if you knew of a more accurate date they planned to ship?
Mr__Anderson has quit [Remote host closed the connection]
<ssvb> TheLinuxBug: I have no idea
<ssvb> and in fact I have a lot of other boards to play with in the mean time :-)
libv has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
IgorPec has quit [Ping timeout: 252 seconds]
libv_ has quit [Ping timeout: 250 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
mozzwald has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
oliv3r has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: No route to host]
nove has joined #linux-sunxi
pekka10 has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
<willmore> I have two Opione boards. Are lima-memtester runs still useful data for them?
<tkaiser> willmore: Sure
<willmore> Okay, I'll dig my boards out and get them powered back up. I just follow the directions on the web site.
<tkaiser> We need at least 10 results. And currently it's 9 ;)
<willmore> Well, then!
<willmore> Let's go to eleven!
JohnDoe_71Rus has joined #linux-sunxi
mozzwald has joined #linux-sunxi
jernej has joined #linux-sunxi
reinforce has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 244 seconds]
<oliv3r> ssvb: btw, i'm sorry :) i'll buy you a fosdem beer next year :)
<ssvb> oliv3r: don't worry about it, nothing really bad happened :)
mozzwald has quit [Ping timeout: 244 seconds]
lamer14648828889 has joined #linux-sunxi
Shirasaka-Hazumi has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
lamer14648828889 has quit [Client Quit]
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
mozzwald has joined #linux-sunxi
zuikis has joined #linux-sunxi
phipli has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
libv has quit [Ping timeout: 250 seconds]
libv has joined #linux-sunxi
<apritzel> montjoie: wens: is there anything that prevents us from posting the sun8i-emac driver?
libv_ has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
Netlynx has joined #linux-sunxi
libv_ has quit [Ping timeout: 276 seconds]
libv_ has joined #linux-sunxi
<montjoie> apritzel: now nothing
<montjoie> I just wait for alain issue to be resolved
<montjoie> apritzel: I think I will try monday to send it
<apritzel> montjoie: oh yeah
<apritzel> I also had to drop pins for the A64
<apritzel> most importantly PD14
libv has quit [Ping timeout: 244 seconds]
<apritzel> which is wired to the PHYRST on the Pine64
<montjoie> ok, i will also add that as comment
<apritzel> I will try to test the driver on the non-plus Pine64 later today
<apritzel> montjoie: I think it's safe to drop any pins that are labelled as "R*MII_NULL"
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
<montjoie> ok
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
<phipli> has anyone got any experience with armbian on an a20 olimex micro?
<phipli> specifically the legacy image
matthias_bgg has quit [Quit: Leaving]
<phipli> HDMI wasn't coming up, so I plugged into the UART
<JohnDoe_71Rus> phipli: native hdmi or use converter?
<phipli> native
tkaiser has joined #linux-sunxi
<phipli> boots up to "<6>axp20_ldo2: 1800 <--> 3300 mV at 3000 mV"
<phipli> and then throws a few (four) dodgy characters and stops
<phipli> (I'm reading this through serial)
libv has joined #linux-sunxi
<phipli> hardware should be fine - not had issues before with OLimex's image
<phipli> time to start reading
libv_ has quit [Ping timeout: 252 seconds]
tkaiser has quit [Ping timeout: 260 seconds]
Nacho has quit [Ping timeout: 260 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
libv_ has quit [Ping timeout: 264 seconds]
Mr__Anderson has joined #linux-sunxi
peepsalot has joined #linux-sunxi
<phipli> so... in virtualbox, to build armbian, should I go 32, or 64bit?
mosterta has joined #linux-sunxi
libv_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
<oliv3r> phipli: 64 :D
<phipli> for any reason other than the number is bigger?
libv_ has quit [Ping timeout: 244 seconds]
<apritzel> phipli: 32-bit is so 1990s!
<phipli> I was mostly 8 and 16 bit in the '90s
<phipli> the host is running 64 bit...
<phipli> just wondering in case there were any toolchain issues
IgorPec has joined #linux-sunxi
<apritzel> phipli: I guess you get better/more modern toolchains for 64-bit
libv_ has joined #linux-sunxi
<apritzel> montjoie: works on the 100MBit Pine64 as well
libv has quit [Ping timeout: 244 seconds]
alain has joined #linux-sunxi
libv has joined #linux-sunxi
<alain> montjoie: regarding the systemd issue I mentioned earlier, after further investigation this is linked to timeouts in mounting disk devices, so nothing to do with the emac driver.
apritzel has quit [Ping timeout: 244 seconds]
<montjoie> alain: thanks for the info, nothing prevent me for sending it:)
<alain> montjoie: I understand your kernel has been more recently rebased than wens', means the USB disk timeout issue I'm having is likely gone in the mainline tree, correct?
libv_ has quit [Ping timeout: 240 seconds]
<alain> hmmm actually, thinking about it, it's the other way around
<montjoie> probably
<alain> yours is more recent and has the USB timeout issue
<alain> crap
<montjoie> so keep wens one for the moment:)
libv_ has joined #linux-sunxi
<montjoie> alain: you could also try to bisect the problem
fredy has quit [Excess Flood]
tkaiser has joined #linux-sunxi
fredy has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
tkaiser has quit [Ping timeout: 276 seconds]
Amit_t_ has quit [Quit: Page closed]
alain has quit [Quit: Page closed]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
JohnDoe0 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
libv_ has joined #linux-sunxi
tkaiser has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
tkaiser has quit [Ping timeout: 246 seconds]
libv_ has quit [Ping timeout: 260 seconds]
<KotCzarny> willmore: as long you see the spinning cube, test is ok
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
cosm has joined #linux-sunxi
libv_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
libv has quit [Ping timeout: 264 seconds]
ornitorrincos_ has joined #linux-sunxi
ornitorrincos has quit [Quit: ZNC - http://znc.in]
<jrg> my bitcoind blockchain on the bananapi is up to 20160416
ornitorrincos_ has quit [Quit: ZNC 1.6.3 - http://znc.in]
ornitorrincos has joined #linux-sunxi
ornitorrincos has quit [Changing host]
ornitorrincos has joined #linux-sunxi
<phipli> jrg : taking it you're mining for fun? :)
IgorPec has quit [Ping timeout: 260 seconds]
<phipli> I was disappointed to be told by a very serious bitcoin friend that almost everything other than dedicated hardware isn't massively profitable these days :(
<phipli> I was locking for FPGA projects at the time, so it was a little bit of a disappointment
<jrg> phipli: naw. not even mining
<jrg> although i might try just for giggles. but i'm guessing without the gpu probably won't happen
<phipli> I always kick myself
<phipli> I heard about bitcoin really early on through a friend who now runs a bitcoin bank...
<phipli> but didn't bother
<jrg> lol
<phipli> I boinc'd instead
<jrg> don't kick youself too much for it :) he is probably in jail now
<phipli> to keep my room warm at uni
<phipli> not that I know :)
<jrg> btc has had quite a spike lately. not sure what that' about
<phipli> keeps showing up in news articles
<phipli> I wonder how long it would take to mine a coin on a 6502...
<phipli> heh
alain has joined #linux-sunxi
<jrg> lolol
<jrg> not even sure if the bpi would have gpu support for mining coins but nowadys it just isn't worth it
<jrg> you might as well just trade it like any other currency
<jrg> buy low sell high
<jrg> wait until you extend past your "bitcoin bank" fees for money xfers to an actual account
<jrg> i mean it would be great if btc were more widely accepted :)
<phipli> yeah. better off just making things
<phipli> better markup
<jrg> not having a world currency is a bit foolish. especially with who is printing the money
<phipli> <cough> ringmodulators <cough>
tkaiser has joined #linux-sunxi
<alain> montjoie: bad news, I had another occurence of my OPI Plus network connectivity dropping, solved by a simple ifdown && ifup. No specific kernel messages.
<jrg> alain: that can't be good. mine is one the way. an opi plus 2e
<jrg> it is somewhere in the docks of new york city heh
<phipli> in the water?
<jrg> lol. the tracking just said it made it to new york
<jrg> it still has to get here in chicago
<phipli> perhaps it is seeing the sights first
<alain> jrg: I'm jealous, mine is the old version with half the ram and emmc
<jrg> phipli: some wiseguy is going to steal the truck :/
<phipli> jrg : as long as they make good use out of the OPi :)
tkaiser has quit [Ping timeout: 240 seconds]
<phipli> someone pinched some tools from next door today
<jrg> like running their booking operations? :/
<phipli> not massively pleased about that
<jrg> then i'd have to fill out a customer form on aliexpress
<phipli> I have a ethernet cctv camera...
<phipli> but the fact I managed to log into it and get a busybox session makes me nervous about it...
<phipli> given that I managed to do so with some half arsed googling
<phipli> the end result is that I'd rather not /reduce/ my security with a security product and so it isn't set up. Probably safest use for it would be to just bolt it to the wall and leave it off
<alain> phipli: I want one as well, but the crap security is a concern .... unless I can replace the sw by a clean copy of openwrt
<phipli> the one I have seems to have some standardised hardware
<phipli> and you can re-flash it
<phipli> someone has done some work on the firmware
<alain> hmm what's the camera name / model?
<phipli> but... I'm not impressed with the quality of the software
<phipli> hardware build quality is way better than I expected though. Just getting a link.
<phipli> there is a 1080 version too
<alain> usual story with chinese manufacturers, good hardware, great value for money, but terrible software
<phipli> one of the things I don't like is that by default they call home (for your convenience)
<phipli> to make them plug and play, they put a /lot/ of work into hacking their way out of your network.
<alain> I have an audio amp ordered from Aliexpress, paid around $150 for it, best audio quality ever, can do Airplay over wifi, but full of bugs
<jrg> alain: sounds like the banana pi :)
<alain> thanks for the link
<phipli> what I really don't like is that I turned every sodding thing I could find to do with that off... and it is still heavily using my upload every time I plug it in!
<alain> I have a policy of only buying stuff that can be re-flashed with decent software, e.g. openwrt
<phipli> Considering setting up a second offline network
<jrg> although with a heatsink and running it at 1.2GHz... it's been a bit more solid
<phipli> I like banggood - they take paypal.
<phipli> This is the innards of that camera : http://marcusjenkins.com/linux/hacking-cheap-ebay-ip-camera/
<jrg> "our victim" lol
<phipli> the flash on mine contained the same image as far as I could see
<phipli> I have to say I like using things for more than one job - why shouldn't my watch be running a bash script to check tomorrows weather and email me to tell me if to catch the bus or cycle?
<phipli> oh yeah - another issue with the Escam was an over dependence on windows
<phipli> web interface doesn't give you all the options if you log in from Linux
<jrg> wow @ shodan.io
<jrg> it's like a worldwide port scanner lol
<phipli> yeah
<phipli> scary isn't it
<jrg> yeah sort of
<phipli> the more I learn, the more I want to live in an electromagnetically sealed box in the woods
<jrg> my domain doesn't have muh tho heh
<phipli> possibly underground
<jrg> the trick is to just not let people know you have anything to take
<jrg> live humble heh
<phipli> :)
<phipli> I like to think that nobody that would break in would value my most prised possessions
<phipli> they can have the TV
<phipli> I can replace that tomorrow
alain has quit [Quit: Page closed]
<jrg> haha
<jrg> they're going straight for the Pis :P
<jrg> and servers
nove has quit [Quit: nove]
<phipli> :'(
<phipli> as long as they don't touch the chickens or the synths
<jrg> chickens?
apritzel has joined #linux-sunxi
<phipli> we have four chickens
<phipli> they're awesome
Andy-D_ has quit [Ping timeout: 258 seconds]
<phipli> not ours, but interesting : https://www.youtube.com/watch?v=2F5kLv6ErOA
vagrantc has joined #linux-sunxi
tkaiser has joined #linux-sunxi
Ultrasauce_ has joined #linux-sunxi
Ultrasauce has quit [Ping timeout: 276 seconds]
tkaiser has quit [Ping timeout: 258 seconds]
Andy-D has joined #linux-sunxi
<jrg> wow
<jrg> kind of figured chickens were a bit more dumb
<phipli> they make really good pets
<phipli> we've had them from when they were young, so they're really friendly. I'd say smarter than cats, dumber than dogs
<phipli> although it might just be that they're easier to motivate with food than cats...
<willmore> KotCzarny, Not sure I'll be running them with a display, but thanks for the tip. I do want to see the spinning qube. Is this the infamous lima spinning cube?
Mr__Anderson has quit [Remote host closed the connection]
<phipli> This evening I have achieved almost nothing - I spent ages compiling armbian from source... only to run out of space on my VM
<phipli> balls
<vagrantc> apritzel: i've tried some of your a64 linux branches for pine64, but haven't found one that can mount a rootfs ... but maybe i'm missing some obvious kernel configuration options?
<vagrantc> apritzel: tried a64-v5 which didn't even successfully load from u-boot, and a64-wip, which gets serial console output, but crashes before loading the initramfs
<apritzel> vagrantc: it's a64-v5 which should give you the best results
<apritzel> vagrantc: and try to avoid to play with configs
<apritzel> it's arm64, just use "make defconfig"
<apritzel> a64-v5 gives you UART, I2C, MMC and Ethernet
<vagrantc> apritzel: well, i always base it on debian's config and then try to add features as needed.
<vagrantc> apritzel: but i'll give it a whirl with make defconfig
<apritzel> but I guess debian's arm64 config doesn't enable the new sunxi bits needed?
<apritzel> which got upstream with 4.6
<apritzel> or not even there
cosm has quit [Quit: Leaving]
<vagrantc> i think i added +CONFIG_ARCH_SUNXI=y +CONFIG_SUN8I_EMAC=m +CONFIG_PHY_SUN4I_USB=m
tkaiser has joined #linux-sunxi
<apritzel> you need CONFIG_MMC_SUNXI
Nyuutwo has quit [Ping timeout: 240 seconds]
<vagrantc> that ethernet driver's the same used on H3? nice...
<apritzel> yup
<apritzel> in fact the whole A64 SoC is very much like the H3, just with A53 cores: http://linux-sunxi.org/A64#Overview
tkaiser has quit [Ping timeout: 252 seconds]
<vagrantc> what's odd is u-boot hangs trying to load the kernel image ...
<vagrantc> load mmc 0:1 $kernel_addr_r ... and nothing
<vagrantc> when i try loading an older attempt based on 4.6.x with some of the a64 patches applied, it actually boots
<apritzel> vagrantc: what is $kernel_addr_r? and do you have ATF running (are you running my firmware image?)
<vagrantc> apritzel: i tried building my own image, but eventually grabbed your image
<vagrantc> don't really grok ATF too well or boot0
<vagrantc> printenv kernel_addr_r
<vagrantc> kernel_addr_r=0x40080000
<vagrantc> works fine for the 4.6.x kernel, but hangs when trying to load a 4.7.x based kernel
<apritzel> that is weird
<apritzel> => load mmc 0:1 $kernel_addr_r Image
<apritzel> reading Image
<apritzel> 12731392 bytes read in 1276 ms (9.5 MiB/s)
<vagrantc> hanging after loading it, that wouldn't surprise me... but actually hanging u-boot just trying to load it?
* vagrantc shrugs
<apritzel> vagrantc: can you try another SD cardddddddddddd
<vagrantc> apritzel: not a bad idea
<apritzel> (wow, key stuck!)
<vagrantc> apritzel: altough i think i only have more cards from the same batch handy
<apritzel> or delete the file from the card and write it again
<vagrantc> they're definitely cheap cards
<apritzel> in case there is a faulty sector on that one card
<vagrantc> or moving the file aside and re-copying it
<apritzel> yes
<vagrantc> then the bad sector will stay bad
<vagrantc> loads the 32MB initrd just fine
<vagrantc> but something seems to hang loading the 4.7.x kernel still ... will try another sd
Nyuutwo has joined #linux-sunxi
<vagrantc> following the labrynth of how it switches from 32 to 64 bit during boot was a little mind-boggling
<apritzel> indeed it is!
<apritzel> I was wondering if this ASCII art is useful or if it actually increases the confusion: https://gist.github.com/apritzel/c40cde0494cda60064f565cd62263b67
<vagrantc> => load mmc 0:1 $kernel_addr_r vmlinuz-4.7.0-rc1
<vagrantc> 12730880 bytes read in 64404 ms (192.4 KiB/s)
<vagrantc> ok, that's progress
<vagrantc> => load mmc 0:1 $kernel_addr_r Image
<vagrantc> 12730880 bytes read in 1035 ms (11.7 MiB/s)
<vagrantc> but... why is it so slow
<vagrantc> those files are identical.
<apritzel> mmh, 192KB/s
<vagrantc> bit-for-bit identical
<apritzel> did it actually take so long? Or is U-Boot a bit off here with the timing?
<vagrantc> it took long enough for me to think it was hung
<vagrantc> and the other was almost instant
<vagrantc> this is where u-boot lacks a bit of user feedback
<vagrantc> it booted!
<apritzel> \o/
mosterta has quit [Ping timeout: 264 seconds]
<vagrantc> ok, so with a64-v5 ... still lacks USB?
<apritzel> should be within reach
<apritzel> you could try to pick some bits from the -wip branch
<vagrantc> and then try to reduce the config down to what's needed to enable for Debian
<vagrantc> of course, the point is somewhat moot until it gets merged in mainline
<apritzel> namely the DT parts and that one patch for the multiple reset lines