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
iamfrankenstein has joined #linux-sunxi
majosa has quit [Quit: Finished]
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<mdsrv> another question
<mdsrv> is a java application for video playback a feasible idea?
Gerwin_J has joined #linux-sunxi
scream has quit [Remote host closed the connection]
mzki has quit [Ping timeout: 260 seconds]
Andy-D has quit [Ping timeout: 260 seconds]
alexxei has quit [Read error: Connection reset by peer]
alexxei has joined #linux-sunxi
lerc has quit [Ping timeout: 252 seconds]
lerc has joined #linux-sunxi
Colani1210 has joined #linux-sunxi
Colani1200 has quit [Ping timeout: 245 seconds]
alexxei has quit [Read error: No route to host]
alexxei has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Andy-D has joined #linux-sunxi
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
alexxei has quit [Ping timeout: 268 seconds]
premoboss has quit [Ping timeout: 265 seconds]
berenm has quit [Quit: berenm]
Andy-D has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
dr1337 has joined #linux-sunxi
arossdotme has quit [Quit: Ex-Chat]
arossdotme has joined #linux-sunxi
arossdotme has quit [Remote host closed the connection]
alexxei has joined #linux-sunxi
alexxei has quit [Read error: No route to host]
alexxei has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
pg12 has quit [Ping timeout: 244 seconds]
pg12 has joined #linux-sunxi
arossdotme has joined #linux-sunxi
IgorPec has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
Andy-D has quit [Ping timeout: 248 seconds]
ojn has quit [Ping timeout: 250 seconds]
Tartarus has quit [Ping timeout: 260 seconds]
bugzc_ns has quit [Ping timeout: 245 seconds]
Andy-D has joined #linux-sunxi
terra854 has joined #linux-sunxi
bugzc_ns has joined #linux-sunxi
Tartarus has joined #linux-sunxi
ojn has joined #linux-sunxi
renze has quit [Read error: Connection reset by peer]
<KotCzarny> mdsrv: go, check it, but short answer is 'no'
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 246 seconds]
premoboss has joined #linux-sunxi
f0xx has joined #linux-sunxi
scream has joined #linux-sunxi
whaf has joined #linux-sunxi
jernej_ has joined #linux-sunxi
whaf has quit [Client Quit]
JohnDoe_71Rus has joined #linux-sunxi
scream has quit [Ping timeout: 258 seconds]
jernej_ is now known as jernej
scream has joined #linux-sunxi
<jernej> ssvb: We figure out the issue with mali driver on 2 GiB boards. Drivers should not convert physical and bus address
<jernej> ssvb: Maybe this would work also on lima memtester
<jernej> ssvb: In short, mali driver should not substract SDRAM base from physical address
<ssvb> jernej: yes, this kind of problem is related to the conversion between physical and bus addresses
<ssvb> do you have a patch?
<jernej> ssvb: Please check Armbian repo
<ssvb> which repo?
<ssvb> no commit message?
<ssvb> and "Needs testing"?
<ssvb> so does it work?
<jernej> ssvb: I discovered that during writing u-boot hdmi driver
<jernej> and zador tried same thing on mali driver
<jernej> he says it's working
<jernej> but it was tested just on few boards
<ssvb> still the patch is very messy
<jernej> true
<ssvb> it changes a lot of things, such as the irq numbers, etc.
<jernej> I guess you'll be quicker if you just try to change that by yourself.
<jernej> given that it already works on other H3 boards
<ssvb> well, one of the things done by this patch is the removal of my old bus/phys addresses bugfix
<jernej> this patch was never meant to be general. It needs to work only for H3
<ssvb> and you are saying that this bugfix is in fact hardful now?
<ssvb> *harmful
<jernej> seems so
<ssvb> the idea is that bit 30 in the address does not matter on boards with less than 2GB
leviathanch has joined #linux-sunxi
<ssvb> but when we have 2GB, then we need to be very careful about how this is calculated
<ssvb> the CPU accesses DRAM using 0x40000000 address as the base offset
<ssvb> but the Mali accesses the DRAM using 0x00000000 as the base offset, that's why a correction is necessary
<ssvb> at least that's how it worked on A20, maybe they have changed something on H3
<jernej> maybe they rewire it? I really don't know the cause, as I'm not expert for memory, but I know, that this patch works
<jernej> anyway, U-Boot driver code also doesn't use Mali
<jernej> and it was similar problem
<jernej> maybe it is Display Engine 2 issue?
<ssvb> yes, the conversion between bus and physical addresses is a generic problem
<ssvb> how does Display Engine 2 address memory?
<ssvb> does it use the same addresses as the CPU or needs a 0x40000000 correction?
<jernej> It works with same addresses
IgorPec has quit [Ping timeout: 256 seconds]
<jernej> as CPU
<jernej> it seems that all units works in this way
bugzc has joined #linux-sunxi
<ssvb> OK, then bus and physical addresses are likely the same on H3, this makes it much easier and less error prone
<ssvb> thanks, I'll try this fix
<ssvb> it's just a single line change
<jernej> ok, no problem
lemonzest has joined #linux-sunxi
jernej has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
premoboss has quit [Ping timeout: 256 seconds]
jstein has joined #linux-sunxi
gianMOD has joined #linux-sunxi
alexxei has quit [Ping timeout: 246 seconds]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
reinforce has joined #linux-sunxi
cptG_ is now known as cptG
alexxei has joined #linux-sunxi
<cptG> hello! On mainline linux with A20, I have buzzing on the headphone jack when nothing is playing (few seconds delay from stop to buzz). It's fine if sth is playing on volume 0. I tried setting power/control from "auto" to "on" in sysfs but that didn't help. Any ideas what state the codec is entering to cause the buzzing and how to avoid it?
mzki has joined #linux-sunxi
alexxei has quit [Ping timeout: 244 seconds]
<cptG> I can control the time-span from stop to buzz via cdc/pmdown_time but I can't turn off the behaviour completely...
paulk-collins has joined #linux-sunxi
jernej has joined #linux-sunxi
<KotCzarny> cptg: usb interference noise?
<KotCzarny> its just that audio path is crappy there
<cptG> Hm. That would not explain the few seconds of non-buzzin I'm getting? The buzzing seems do happen when the device is in some sort of "power off" state.
<cptG> ...everything is fine when the device is in use, there's no buzzing even when the device is muted. But if whatever player is playing is stopped, the buzzing start after the milliseconds value configured in cdc/pmdown_time
leviathanch has quit [Read error: Connection reset by peer]
<cptG> I can set that to 2147483647, which gives me 24 days of silence when no player is running inbetween, which should be fine I guess :)
<cptG> well, the USB part *could* of course be the cause of the buzzing but that's not something I can fix I'm afraid. Disabling power management completely would work but so far I've had no luck with that.
premoboss has joined #linux-sunxi
<KotCzarny> using i2c audio module could help, or spdif
Mr__Anderson has quit [Ping timeout: 250 seconds]
<cptG> KotCzarny: hum. i2c and spdif are for external audio interfaces, right? Or is ist just another way to talk to the codec hardware?
<KotCzarny> keep in mind when audio codec is closed/powered off, nothing gets amplified/gets on output
<KotCzarny> you might also try hdmi audio out
<KotCzarny> its digital and decoded outside/far from the board might help
Mr__Anderson has joined #linux-sunxi
<cptG> hm... yeah, I had an USB sound card which worked fine but I wanted to explicitly get rid of that to free up an USB port.
<KotCzarny> and i2s is just external audio card unrelated to anything onboard
<KotCzarny> it connects via gpio pins, so usb is free
<cptG> KotCzarny: OK, so I understood that correctly.
<KotCzarny> keep in mind i2c != i2s
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<cptG> KotCzarny: yeah, that was a mistake, I always type i2c first :D
<cptG> So spdif sounds good I guess - I'll get to keep my USB port and just need to get an spdif to anaolg converter.
<KotCzarny> do you have any other device close to the board?
<cptG> Until then: how can I make my value in cdc/pmdown_time permanent? I see no module parameters for sun4i_codec. Anything I can put into modprobe.d to control that value anyways? cdc.pmdown_time=foo?
<KotCzarny> just add it to /etc/rc.local
<cptG> KotCzarny: OK, got it. Thanks!
p_rossak has quit [Ping timeout: 244 seconds]
yann-kaelig has joined #linux-sunxi
Peet has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
bonbons has joined #linux-sunxi
Peet has quit [Ping timeout: 260 seconds]
<tkaiser> ssvb: So how much SPI NOR flash should be soldered to boards to be useful? Just thinking about giving Xunlong/Steven some feedback (eg. solder pads for RTC battery backup)
alexxei has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
<jernej> MoeIcenowy: I checked disassembly and I'm almost sure this is some kind of gcc bug
<jernej> according to this: http://sprunge.us/ciHI one instruction is missing
<jernej> in function hdmi_read_lock
<jernej> in line 18, it should be something like "mov r2, #69; 0x45"
<jernej> workaround would be to write all four bytes at the same time with writel
<jernej> hm... or not
<jernej> anyway, it is weird
<MoeIcenowy> oh I found why the fixed code can run longer
<MoeIcenowy> when you told me to fix it
<MoeIcenowy> you used a writel (0xXXXXXXXX
<MoeIcenowy> not four writel (0xXX
<MoeIcenowy> will try to workaround both read lock and read unlock
<jernej> uh, you might want try to use writeb for single bytes
<jernej> I guess this should work too, but in the final version, I want to use writel with all four bytes written at the same time
<jernej> now I wonder how this even worked
<jernej> MoeIcenowy: For starters, you could just try to replace writel to writeb in those two functions
The_Loko has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 256 seconds]
<MoeIcenowy> jernej: replace writel with writeb works in read_lock
<MoeIcenowy> however
<MoeIcenowy> system stucks after "HDMI connected:" again
<jernej> uh, please make same replacement in sunxi_hdmi_edid_get_mode() also
<MoeIcenowy> still stuck
<MoeIcenowy> will detect the stuck position with printf
IgorPec has joined #linux-sunxi
<jernej> I guess it is stuck in sunxi_hdmi_edid_get_mode(), right before await_completion() call
<MoeIcenowy> died within I2C controller reset code
<MoeIcenowy> yes you got it it's right
<jernej> well that function uses 32 bit read instead of 8 bit
<jernej> could you duplicate it and make it 8 bit for the test?
lerc has quit [Ping timeout: 244 seconds]
<MoeIcenowy> duplicate await_completion?
<MoeIcenowy> it works
<jernej> great, I will fix it
<jernej> thanks for testing
<MoeIcenowy> oh I also replaced some writel with writeb in sunxi_hdmi_edid_get_mode
<mdsrv> how do u know all of this
lerc has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7017-g48dacdb, build type: debug, sources date: 20160102, built on: 2016-11-10 06:12:27 UTC git-7017-g48dacdb http://www.kvirc.net/]
<jernej> which part?
<MoeIcenowy> i2c controller regs set
<jernej> from BSP code
<mdsrv> everything
<jernej> and something from jemk's effort to understand HDMI controller and phy
p_rossak has joined #linux-sunxi
<MoeIcenowy> jernej: how long will you take to tidy the HDMI code up?
<jernej> not sure, depends on how much free time I will have
p_rossak has quit [Remote host closed the connection]
<jernej> but I suppose around the week? there are some register settings which I want to double check first
p_rossak has joined #linux-sunxi
<jernej> MoeIcenowy: Also 4K resolution doesn't work. Based on current informations I have, DE2 is not properly configured for that
<MoeIcenowy> tkaiser: have you tested the OPi0's Wi-Fi?
<tkaiser> MoeIcenowy: Just a little bit and only with BSP driver and since yesterday it doesn't work any more :)
<KotCzarny> lol
<KotCzarny> what did you do to the poor thing?
<tkaiser> KotCzarny: testing different antennas. But that shouldn't be related to the issue (driver claims to not find firmware any more)
<KotCzarny> fried just by testing antennas? o.O
<MoeIcenowy> I'm facing firmware crash when trying to port the driver to mainline
<MoeIcenowy> tkaiser: when the firmware is found it can work?
<tkaiser> MoeIcenowy: Yes, only tested client mode so far
<MoeIcenowy> so I may met another problem
<tkaiser> MoeIcenowy: This is what I get now: http://sprunge.us/DWHf
<MoeIcenowy> tkaiser: could you provide a successful dmesg?
<KotCzarny> tkaiser, might be some static electricity?
<KotCzarny> ie. let it cool for some hours unplugged from everything?
<MoeIcenowy> as I do not want to test it by myself...
<MoeIcenowy> (I do not have extra SD cards
<tkaiser> MoeIcenowy: Somewhere here in between: http://sprunge.us/SZGF (Armbian collects dmesg output on startup and shutdown in a log to easy user support, search for 'wlan0')
<tkaiser> s/easy/ease/
<MoeIcenowy> https://pastebin.anthonos.org/view/1ae74610 could anyone help me to check this dmesg...
<MoeIcenowy> why will the firmware crash...
<KotCzarny> looks similar to tkaiser's
fgfeaf has joined #linux-sunxi
<KotCzarny> also, try to load module again?
fgfeaf has quit [Client Quit]
<KotCzarny> he said something that first load always fails
_fortis has quit [Remote host closed the connection]
jstein__ has joined #linux-sunxi
jstein is now known as Guest82738
jstein__ is now known as jstein
Guest82738 has quit [Ping timeout: 260 seconds]
<MoeIcenowy> tkaiser: do you have a script.fex for opi0?
jernej has quit [Ping timeout: 265 seconds]
premoboss has quit [Ping timeout: 245 seconds]
tithrion has joined #linux-sunxi
gianMOD has joined #linux-sunxi
premoboss has joined #linux-sunxi
gianMOD has quit [Ping timeout: 244 seconds]
petr has quit [Ping timeout: 245 seconds]
petr has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-sunxi
whaf has joined #linux-sunxi
my123 has quit [Ping timeout: 260 seconds]
Keziolio has quit [Ping timeout: 258 seconds]
mzki has quit [Ping timeout: 268 seconds]
my123 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
my123 has quit [Changing host]
my123 has joined #linux-sunxi
oliv3r has quit [Remote host closed the connection]
Keziolio has joined #linux-sunxi
Dodger78_ has joined #linux-sunxi
<Dodger78_> hi guys , is usb3 on A80 working in mainline?
<KotCzarny> a80 status: unsupported (yet)
<Dodger78_> is someone working on it or is this thing "dead" ?
<KotCzarny> someone is
<KotCzarny> but as a80 is already eol dont expect miracles
<Dodger78_> i hate this crappy piece :-) the cubietruck is ok , but my cb a80 is new im my shelf and never saw real operation
<Dodger78_> cubietech is selling unusable hardware basically . wasted money.
<KotCzarny> oh, usb is supported, oh well, then ask wens specifically
<Dodger78_> usb3 ? usb2 isnt worth anything anymore
<KotCzarny> usb2 is okayish
IgorPec has joined #linux-sunxi
oliv3r has joined #linux-sunxi
<Dodger78_> not really: gbit usb3 adapters , usb3 attached disks etc
<Dodger78_> odroid xu4 supports it all on mainline kernel
<tkaiser> IgorPec: Is Wi-Fi with OPi Zero working for you?
<KotCzarny> are you really expecting them to max the bandwidth?
<tkaiser> KotCzarny: USB3
<tkaiser> + UAS on XU4 rocks
<Dodger78_> in times of gbit ethernet and SSDs , yes
<IgorPec> tkaiser: i can see and connect , didn't do any other tests yett
<tkaiser> IgorPec: Strange, for me it isn't working *any more* and I tested latest beta image and get the very same errors
<Dodger78_> odroid xu4 even got HMP and everything supported , allwinner still cant deliver working SMP on mainline after more than 1 year
<IgorPec> tha dhd patch was not ok, so blacklisting is needed
<tkaiser> Dodger78_: Allwinner does nothing here.
<tkaiser> IgorPec: Ah, ok
<KotCzarny> Dodger78_: allwinner still uses linux 3.x, if it wasnt for linux-sunxi guys nothing newer would be available
<Dodger78_> :-) yeah seems so . i will put A80 into the bin , will be my last allwinner device. what a pity after that nice cubietruck
<Dodger78_> A20 is fully supported on mainline thanks to linux-sunxi
<KotCzarny> h3 is quite complete too
<Dodger78_> H3 is still A7 cores . its nothin than a refurbished cubietruck
afaerber has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
jernej has joined #linux-sunxi
<wens> Dodger78_: a80 hmp with PSCI is close
cnxsoft has quit [Read error: Connection reset by peer]
<wens> Dodger78_: if you want SMP through the kernel, i have patches for it, though PSCI is preferred, so those won't get merged
<wens> Dodger78_: and about USB on cb4, usb2 is not merged for some stupid reasons
<wens> Dodger78_: USB3 is a black box someone has to figure out
<Dodger78_> @wens: i only need usb3
cnxsoft has joined #linux-sunxi
<Dodger78_> @wens, so is there still work on a80 mainlining ?
<wens> Dodger78_: i'm working on a80 mainlining
ptx0 is now known as kash
<wens> since i have 2 boards and i would like them to work :)
kash is now known as d[^_^]b
<wens> but i only do this in my free time, sometimes stealing cycles at work, so don't expect miracles :)
<Dodger78_> me 2 ... im very sad about my a80 hardware . i bought it since cubietruck was so great but i wanted usb3 and the power of the a15 cores
<Dodger78_> the board spend almost 2 years in my cupboard now
<wens> yeah, i made those smp patches over a year ago :(
<Dodger78_> :-!
bugzc has quit [Ping timeout: 260 seconds]
Dodger78_ has quit [Remote host closed the connection]
cnxsoft has quit [Quit: cnxsoft]
<tkaiser> IgorPec: still doesn't work for me but maybe I just have a hardware problem. The PSU connected to Micro USB leads to an EHCI device connecting/disconnecting every 0.1 seconds.
<IgorPec> ok, i'll check it
<tkaiser> Maybe something went wrong when I attached a heatsink (using thermal glue, gotta check whether that one is conductive or not ;) )
<IgorPec> image from beta download section, right?
<tkaiser> IgorPec: Yes
<IgorPec> ok, few minutes
<tkaiser> IgorPec: Thank you
premoboss has quit [Remote host closed the connection]
<IgorPec> tkaiser: works out of the box ... now some tests
<tkaiser> IgorPec: If driver loads then it's already confirmed that I might have already damaged my board
<IgorPec> Power Management:on
<IgorPec> is this ok?
<tkaiser> IgorPec: Yes
<IgorPec> but is working very slow
<tkaiser> IgorPec: h3consumption -w off && reboot
<tkaiser> Or 'iwconfig wlan0 power off'
<tkaiser> ;)
<IgorPec> iwconfi wlan0 power off
<IgorPec> should do i thin
<tkaiser> Sure but if you want to disable it permanently the above will lead to a network-manager hook disabling power-management when interface is brought up
<tkaiser> IgorPec: h3consumption creates a simple script /etc/NetworkManager/dispatcher.d/99disable-power-management that does the job from then on
<IgorPec> ok
<IgorPec> 3] 0.0-10.1 sec 17.5 MBytes 14.6 Mbits/sec
<IgorPec> 0.0-10.3 sec 22.1 MBytes 18.0 Mbits/sec
<IgorPec> 0.0-10.2 sec 20.8 MBytes 17.1 Mbits/sec
<IgorPec> it works, that's all i can say out of this. let me try AP mode
<IgorPec> or i can check later. i'll see if it will be still online in next hour. btw. 50cm away from router :)
<tkaiser> IgorPec: Thank you, you could post armbianmonitor -u output for MoeIcenowy online. She asked for it a few hours ago for a working case
lkcl has quit [Ping timeout: 246 seconds]
gianMOD has joined #linux-sunxi
<IgorPec> hmm, i did reboot and it didn't came up
<KotCzarny> case of dying wlans ta doo doo doom.
<tkaiser> IgorPec: do you have the 256 MB version? I experienced sometimes oom killer early in boot process leading to some failures
<IgorPec> yes, just a moment ... seeking another serial console :)
premoboss has joined #linux-sunxi
<premoboss> i need to use the 2 uart of nanopi neo. script.bin is the original one, if i edit it, (bin2fex) i see both uart are cofigured, but i f i try to test those TX with oscilloscope, o cans see chars caming out. any hints?
gianMOD has quit [Remote host closed the connection]
<tkaiser> premoboss: Which script.bin is the original one?
<premoboss> script.bin is a link to bin/nanopineo.bn
<tkaiser> premoboss: Ok, so you're using Armbian? I don't really have an idea but recently Mikhail spotted some wrong settings in a few fex files that should fix a similar case: https://forum.armbian.com/index.php/topic/2114-banana-pi-m2-uart2-only-works-one-way/
<premoboss> yes
<premoboss> i am using armbian 5.23 wuith kernel 4.8.3
<premoboss> updated yesterday
<tkaiser> premoboss: then you can forget about script.bin entirely :)
<premoboss> ok, shann i go with dbs?
<premoboss> dtb
<tkaiser> yes, mainline kernel uses device tree instead.
iamfrankenstein has quit [Read error: Connection reset by peer]
<tkaiser> premoboss: All this stuff on the GPIO headers is currently known to not work properly since we use Orange Pi One .dtb on the NEO with a small patch to enable usb1 and usb2 there
<premoboss> dtb file point to dtb-4.8.3-sunxi
<premoboss> ah, is it the why i cant find a proper dtb for nanopi neo.
<tkaiser> premoboss: Armbian also does not really support mainline kernel on H3 boards, it's just a preview to get some feedback to forward to devs
<premoboss> any chance to have he right one to enbable both uarts?
<premoboss> on nanopineo, i mean
iamfrankenstein has joined #linux-sunxi
lkcl has joined #linux-sunxi
<IgorPec> tkaiser: the board does not boot :)
<tkaiser> premoboss: Sure, but I fear you're on your own here. Check wiki pages for pin-outs and come up with working settings :)
<tkaiser> IgorPec: Great :)
<KotCzarny> igorpec, lol, killer wifi
<KotCzarny> or just very crappy firmware blob
<premoboss> in other words, it is another stick up on the assole....
<IgorPec> i am trying now with fresh start, diff sd card ...
<IgorPec> diff psu i already did ... strange
<IgorPec> i changed cabling on serial console since they were loosy
<tkaiser> IgorPec: Mine boots, just checked Micro USB port and flashed new image through FEL mode.
<IgorPec> other sd card boots here too
<IgorPec> AP mode does not work out of the box
<tkaiser> IgorPec: According to modinfo output only MAC address can be supplied to the driver. Maybe this missing .conf file is responsible for using the various modes?
<tkaiser> IgorPec: '[XRADIO_ERR] Access_file failed, path:/data/xr_wifi.conf!'
<KotCzarny> realtek style?
<KotCzarny> ;)
premoboss has quit [Ping timeout: 250 seconds]
<MoeIcenowy> tkaiser: the file have only mac.
premoboss has joined #linux-sunxi
<IgorPec> but there is something regarding AP in the driver, so some more inspection will be needed
<tkaiser> IgorPec: Do you power currently through Micro USB?
<IgorPec> yes
<IgorPec> [ 498.950269] [STA_WRN] xradio_change_interface: new type=3(2), p2p=0(0)
<IgorPec> [ 498.958505] [STA_WRN] !!! xradio_remove_interface: vif_id=0
<IgorPec> nl80211: Could not configure driver mode
<IgorPec> [ 498.966522] [STA] !!!xradio_vif_setup: id=0, type=3, p2p=0
<IgorPec> nl80211: deinit ifname=wlan0 disabled_11b_rates=0
<IgorPec> [ 499.160750] [STA_WRN] xradio_change_interface: new type=2(3), p2p=0(0)
<IgorPec> [ 499.169201] [STA_WRN] !!! xradio_remove_interface: vif_id=0
<IgorPec> [ 499.177231] [STA] !!!xradio_vif_setup: id=0, type=2, p2p=0
<IgorPec> nl80211 driver initialization failed.
<IgorPec> wlan0: interface state UNINITIALIZED->DISABLED
<IgorPec> wlan0: AP-DISABLED
<IgorPec> hostapd_free_hapd_data: Interface wlan0 wasn't started
<tkaiser> Does dmesg show 'highspeed device connect' / 'highspeed device disconnect' 10 times a second?
<IgorPec> no, nothing in the logs
lkcl has quit [Ping timeout: 245 seconds]
<tkaiser> IgorPec: Replacing the expensive 'german' PSU with a cheap chinese one solved this problem. Obviously noisy DC-IN leads to an unknown 'device' being detected on the OTG port approx 10 times per second :)
<IgorPec> mine works fine. it's attached to chinese type PSU :)
<tkaiser> IgorPec: Nice, replacing the USB cable (20AWG rated) with a crappy one also 'solves' the problem even with the noisy PSU :) So most users won't run into this since the cables most people use (24AWG or even worse) will filter noise.
<tkaiser> IgorPec: And regarding Wi-Fi. After '[XRADIO] Bootloader complete' on your board '[XRADIO] Firmware completed.' is in dmesg output while on mine '[SBUS_ERR] xradio_indirect_read: Prefetch bit is not cleared.'
<tkaiser> Seems like hardware?
<MoeIcenowy> I will soon try legacy kernel Armbian on my board...
<tkaiser> MoeIcenowy: those images here http://image.armbian.com/betaimages/ are nightly builds and replaced the next day. So maybe download http://image.armbian.com/betaimages/Armbian_5.24.161112_Orangepizero_Ubuntu_xenial_3.4.113.7z already since this is known to work. Just want to prevent we change anything and you waste time
<MoeIcenowy> downloaded it
<MoeIcenowy> but I have no more sdcard to test it
<IgorPec> tkaiser: it's hard to say. chip is v1.0, rather 0.1 and the driver is the same :)
<IgorPec> btw
<IgorPec> E: fexc-bin: Malformed data: version 35152.1.2.
<IgorPec> bin2fex script.bin script.fex
<IgorPec> on those images
<MoeIcenowy> does xr816 have different versions?
<MoeIcenowy> xr819 *
<IgorPec> never hear of this chip before .. is some AW wanna be wifi chip maker
<tkaiser> MoeIcenowy: So far dmesg printed on all boards: '[XRADIO] XRADIO_HW_REV 1.0 detected.'
<MoeIcenowy> yes also on my board.
<IgorPec> Link Quality=70/70 Signal level=-24 dBm
<NiteHawk> IgorPec: please grab up-to-date sunxi-tools straight from the github repo. the version check has been fixed by now
<IgorPec> nitehawk: tnx. i'll check up
arossdotme has quit [Ping timeout: 240 seconds]
lamer14790520375 has joined #linux-sunxi
lamer14790520375 has quit [Client Quit]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
tkaiser has quit [Ping timeout: 248 seconds]
<Wizzup> can anyone suggest a somewhat ok a10/a20 tablet?
<Wizzup> er, let me check the wiki.
gianMOD has quit [Remote host closed the connection]
tithrion has quit []
tkaiser has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<Wizzup> well, that was quite a search
<Wizzup> found some seemingly nice a20 one in russia
f0xx has quit [Ping timeout: 256 seconds]
premoboss has quit [Ping timeout: 260 seconds]
<willmore> Wizzup, I think I have an A10 based one that I had forgotten about. It's a little 4" tablet. I should look into doing something with it. :)
<Wizzup> heh :)
<Wizzup> I'm looking for some nice tablets to test maemo-ports on
<|Jeroen|> arent a20's old?
<|Jeroen|> think i got one in my old crapy banannapi
<Wizzup> I don't care about old, only about usable
<|Jeroen|> what would make it more usable then new ones?
<KotCzarny> do those a20 tablets have sata port exposed somehow?
jernej has quit [Ping timeout: 260 seconds]
jstein has quit [Remote host closed the connection]
<Wizzup> |Jeroen|: mainline support is a must
<Wizzup> for me anyway
<|Jeroen|> yeah but the A64 works with mainline, and it should be a lot fastr
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 245 seconds]
iamfrankenstein1 is now known as iamfrankenstein
vagrantc has quit [Quit: leaving]
<mripard> |Jeroen|: you're being overly optimistic :)
<|Jeroen|> well it worked for what i wanted :p
<tkaiser> |Jeroen|: Headless tablet?
<|Jeroen|> nah home automation on a pine64
<|Jeroen|> jst need ethernet and i2c
<tkaiser> |Jeroen|: So different use case obviously ;)
<|Jeroen|> i guess so, but why headless tablet isted of a dev board?
<tkaiser> |Jeroen|: You were asking why an A20 tablet would be interesting. Simple: Support for relevant hardware parts
<|Jeroen|> well i didn't knew it was about tablets :p
<tkaiser> BTW: Do you know how much Pine Inc charged for shipping?
<|Jeroen|> dunno, i won 2 of them :p
<|Jeroen|> there are nice, but damn big
* jelle has some hopes for the orange pi 2
<tkaiser> jelle: OPi 2, OPi PC 2, OPi Plus 2, OPi 2 Mini?
<jelle> tkaiser: the first!
<jelle> wait the OPi PC 2
<KotCzarny> ;)
<tkaiser> jelle: LOL
<jelle> damn so many OPi's again
* jelle just wanted a64
<|Jeroen|> yeah a load of o pi's
<tkaiser> jelle: I would wait for the OPi PC 2 Plus (with WiFi and eMMC then) ;)
<|Jeroen|> ow emmc coud be nice
<jelle> I like the OPi zero
<jelle> it looks nice
<jelle> better then the nanopi probably
leviathanch has joined #linux-sunxi
<tkaiser> jelle: Not necessarily 'better' but with a few interesting hardware details. NanoPi NEO PCB rev 1.1 or above are also great for IoT stuff
<jelle> tkaiser: hmm I wonder if I have that rev 1.1
<jelle> tkaiser: I hate some heating issues, but then I stopped having them. Unsure if that's because it's winter now
<tkaiser> jelle: If it overheats badly you've rev 1.9
<jelle> *had
<tkaiser> 1.0
<jelle> ahh
<tkaiser> jelle: It's also printed on the PCB
<jelle> tkaiser: for my IoT stuff I just have a nodemcu esp8266
<tkaiser> |Jeroen|: For home automation stuff Pine64 is way too inefficient. Idle consumption 3 times higher compared to OPi Zero ;) https://github.com/igorpecovnik/lib.docs/blob/master/docs/board_details/pine64.md
<jelle> hehe
<|Jeroen|> ow is it?
<|Jeroen|> haven't measured it yet
<|Jeroen|> thanks for the tip, maby i must consider other devices then
<tkaiser> |Jeroen|: the board itself with mainline kernel will consume a bit more than 1W when using Fast Ethernet. That's most probably less than the idle consumption of a crappy PSU
<KotCzarny> make it live on air
<jelle> nanopi neo also had a nice low power consumption :)
<|Jeroen|> thats not much
<jelle> KotCzarny: s/air/solar/g :D
<|Jeroen|> but they have low ram ?
<KotCzarny> bad region for solars ;)
<|Jeroen|> i like atleast 1GH
<|Jeroen|> B
<jelle> KotCzarny: same here, don't live in the desert :p
<tkaiser> |Jeroen|: 1GB to query sensors?
<jelle> |Jeroen|: zero has 512 I think?
<KotCzarny> it can also double for other taskss
<|Jeroen|> well it does more then query sensors
<|Jeroen|> runs a postgres db and webinterface
<terra854> Just wondering, is the H5 better than the A64?
<|Jeroen|> and i would like to run the postgrey on a ramdisk in the future
<|Jeroen|> well its actualy running fine on a old pi1 atm, but wanted to switch it to the pine beceause i won then
<KotCzarny> you can still sell them while they are hot
<KotCzarny> ;)
<|Jeroen|> would be to costly to chip them from here
<|Jeroen|> and i do like the idea of 64bit :p
<|Jeroen|> not that i actualy mathers
<KotCzarny> which part of it exactly has a use for you?
<|Jeroen|> jus network and i2c
Pepe has joined #linux-sunxi
<KotCzarny> you know that even a10/a20 fits in those criteria perfectly?
<|Jeroen|> yeah but i have a A20 on a bananna pi and it ws crap
<|Jeroen|> needed 2 psu's etc
<KotCzarny> w00t?
<|Jeroen|> yeah crapy chinese hardware
<KotCzarny> why 2 psu?
<|Jeroen|> its was on the wiki, otherwise it might not boot
<KotCzarny> lol?
<|Jeroen|> actualy i even blew one up
<KotCzarny> [citation needed]
<|Jeroen|> crap!!
<KotCzarny> if you talk about needing 12V for 3.5" hdd, google: meanwell rd-65a
jernej has joined #linux-sunxi
<KotCzarny> (i should do some photo documentation of my banana setup)
<tkaiser> |Jeroen|: So PostgreSQL is broken by design?
<|Jeroen|> nah sd cards are broken by design
<|Jeroen|> run a postrges on a sd card and its breaks in a few months
iamfrankenstein has quit [Ping timeout: 245 seconds]
<tkaiser> terra854: depends on what you're keen on whether H5 is better or not. Just look into the wiki
iamfrankenstein has joined #linux-sunxi
<tkaiser> |Jeroen|: Exactly, so choose an A20 device with native SATA and run databases from an SSD
<jelle> wonder when that new A20+ is released with native SATA :)
<|Jeroen|> that would also be an option
<|Jeroen|> i do have the banana pi with sata lying collecting dust
<|Jeroen|> but i don't trust it
<tkaiser> |Jeroen|: And BTW: postgresql devs aren't morons, so by adding a 'ramdisk' you just decrease both reliability and performance. BTW: SATA with A20 sucks somewhat when it's about sequential write speeds but that doesn't matter that much when it's about databases: https://forum.armbian.com/index.php/topic/1440-h3-devices-as-nas/?p=11423
<tkaiser> jelle: R40, BananaPi M2 Ultra (or something like that). Already an aliexpress but moronic vendor provides no benchmark numbers for GbE and SATA
<|Jeroen|> yeah i agree its not the best option
<jelle> tkaiser: :D
<|Jeroen|> thats why i now run the postgres on another server with disks
<jelle> tkaiser: yeah exactly that R40
<|Jeroen|> but i would prefer it all on one controller
<tkaiser> |Jeroen|: your problems were related to crappy Micro USB used for DC-IN, simply power the board through SATA power and A20 runs pretty stable.
* jelle notes this
<|Jeroen|> nah, that board is going nowhere :p
<terra854> tkaiser: Apparently H5 has a stronger GPU (Mali 450)
<terra854> tkaiser: But i don't think it will matter due to blobs and licensing issues preventing us from using it
<tkaiser> |Jeroen|: Banana Pi was always the best performing A20 device for me (GbE throughput). And it's pretty simple to get this sinovoip crap stable: Avoid Micro USB to power the boards and you're already done
<terra854> tkaiser: Other than that, the CPUs are the same (4x Cortex A53)
<tkaiser> terra854: For my use cases H5 has twice as much USB ports compared to A64, that's twice the IO bandwidth and allows for more use cases.
<|Jeroen|> allwinner makes to many models :p
<tkaiser> terra854: Also chances are great that OPi PC2 and 3 won't suck regarding Gigabit Ethernet.
<jelle> I love how there is a H2 now
<jelle> H3 => H2 :D
<Pepe> Hello guys. I would like to know which board from Sunxi is better for Android?
cptG_ has joined #linux-sunxi
<jelle> don't think many people use android here :)
<tkaiser> Pepe: None
<Pepe> Thanks. That's what I would like to know. :D
<terra854> Pepe: Unless you are fine with Allwinner's provided crap
<Pepe> Was just asking, but othe other side I was checking newly released Orange Pi PC2 which looks good, because mainline support is on the way. Still can't decide between it and Orange Pi Plus 2E
cptG has quit [Ping timeout: 245 seconds]
<tkaiser> Pepe: None of Allwinner's current line up has a GPU that meets Android 7 requirements and when using Android it's essential to boot from storage showing high random IO performance (fsync). The average SD card out there horribly sucks here.
<tkaiser> Pepe: H3 means Android 4.4 max. Good luck.
<Pepe> I would be fine also with Android 6, but I joined this channel to directly ask you, because I see from CNXSoft that you're smart guy and you could help me, which you did about Android.
<KotCzarny> pepe: forget about android from allwinner vendors, its broken, incomplete and no one really cares
<Pepe> now I understood it, thanks.
<KotCzarny> if you really want android, buy some branded tablet
netlynx has quit [Quit: Ex-Chat]
yann-kaelig has quit [Quit: Leaving]
gianMOD has joined #linux-sunxi
<KotCzarny> or some ott box
<KotCzarny> those might have a bit better support
<KotCzarny> for me original bananas are stable, feature packed and best of all mainlined
<KotCzarny> (that is, as long you use good distro, psu and cable)
<Pepe> and for linux I cant decide between Pi PC2 (but waiting for 2 GB RAM) or Pi Plus 2E. Which would have better mainline support right now.
<KotCzarny> h3 one, but h5 is very similar to h3
<KotCzarny> so it might get same feature status as h3
<jonkerj> until the emac patches reach mainline (my feeling is we're not far away) you will be needing some patches for H3
gianMOD has quit [Ping timeout: 260 seconds]
<jonkerj> I am running not that many patches (emac + dvfs) on my h3 boards (orange pi plus, orange pi pc)
<jonkerj> used to be a lot of patches, but most is mainlined now
gianMOD has joined #linux-sunxi
<tkaiser> jonkerj: megi's repo contains most of them already: https://github.com/megous/linux/commits/orange-pi-4.9
<KotCzarny> tkaiser, is that what you use for armbian betas for h3?
<jonkerj> I know
<jonkerj> but that's still not technically mainline, but patched mainline
<jonkerj> just saying
<tkaiser> KotCzarny: Nope, we switched to https://github.com/montjoie/linux/tree/sun8i-emac-wip-v5 recently since freezes occured. But I changed back to megi's repo on Orange Pi Zero
<KotCzarny> mhm
dh1tw has quit [Quit: Textual IRC Client: www.textualapp.com]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
premoboss has joined #linux-sunxi
<ssvb> NiteHawk: I tried to remove the word "hacking" from the project description at https://github.com/linux-sunxi/sunxi-tools
<ssvb> But it is still listed in the readme.
<ssvb> Having blogs like http://hackaday.com/2016/11/13/linux-on-your-nes-classic-edition/ may attract attention of Nintendo lawyers, so it's best to ensure that these people don't get any weird idea about what it is.
<jelle> should update the arch package description too then =)
<KotCzarny> and remove any traces from google memory
<jelle> ssvb: description is now quite long though
<ssvb> jelle: you are welcome to suggest a better description
<KotCzarny> maintenance tool
<KotCzarny> ;)
<NiteHawk> ssvb: I'm with jelle there - keep the headline short, any more detailed description should go into the README instead
<KotCzarny> tricks isnt too serious neither
<KotCzarny> sunxi maintenance suite
<jelle> "sunxi development tools"?
<NiteHawk> ssvb: btw, i'd like to also tackle the "sram info" vs. "soc info" terminology change - what do you think of https://github.com/n1tehawk/sunxi-tools/commit/c57ccffb907aa216625f05773ca006f7dd49b4b0 ?
<KotCzarny> jelle, i guess it should be something more soc related than sdk
<jelle> KotCzarny: well sunxi represents all the Allwinners SoC's right?
lkcl has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
<NiteHawk> just keep it neutral: "A collection of command line tools for ARM devices based on Allwinner SoCs." ?
iamfrankenstein has quit [Ping timeout: 245 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<jelle> sounds good
<ssvb> NiteHawk: moving this code to separate files is a good idea, but it probably should have my copyright too :-)
<ssvb> NiteHawk: because I'm the author of maybe more than 50% lines of code in this particular part
Andy-D_ has quit [Ping timeout: 245 seconds]
<NiteHawk> ssvb: right, no objections from my side :)
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
<premoboss> why armbian came in 2 version, ubuntu and debian? not better to focus all the effort only on the best one, debian?
leviathanch has quit [Remote host closed the connection]
<KotCzarny> because they are not that different
Andy-D__ has joined #linux-sunxi
<tkaiser> premoboss: All 4 can be debootstrapped so it's just a matter of keeping track of some package dependencies.
Andy-D_ has quit [Ping timeout: 248 seconds]
ericxdu has quit [Remote host closed the connection]
ericxdu has joined #linux-sunxi
ericxdu has quit [Remote host closed the connection]
ericxdu has joined #linux-sunxi
mzki has joined #linux-sunxi
utente_ has joined #linux-sunxi
premoboss has quit [Ping timeout: 252 seconds]
gianMOD has quit []
jrg has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
jrg has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
utente_ has quit [Ping timeout: 258 seconds]
<plaes> o/
<plaes> is there a way to enter FEL mode from u-boot?
utente_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> ssvb: NiteHawk: has it ever been discussed to extend for instance uart0-helloworld to give more info?
<apritzel> or to integrate some informational command in sunxi-fel?
<apritzel> I have something like this in my OPi PC 2 NOR flash at the moment:
<ssvb> haha, I used exactly the same modification of uart0-helloworld for retrieving REVIDR, even the format of the output is roughly the same :-)
|Jeroen| has quit [Remote host closed the connection]
<apritzel> ;-)
<ssvb> but yes, it makes sense to just integrate retrieving this information into the sunxi-fel tool
<apritzel> right, I was thinking so
<NiteHawk> apritzel: so far it's been mostly a "proof of concept" or having some 'baremetal' code running. but once you get the UART going, you can of course use it for diagnostic purposes - so yes, that makes sense
<apritzel> ssvb: putting it into sunxi-fel tool would simplify new SoC bootstrapping, as we don't need to know how the UART works
<NiteHawk> ah sorry, i mixed that up - thought you were referring to uart0-helloworld
<apritzel> NiteHawk: actually both
<apritzel> I think having some bare-metal hello world is useful
<apritzel> because quite some people ask for it
<apritzel> we could just point them to it
<apritzel> another thing is new SoC bringup
<NiteHawk> as far as "register-poking" is concerned, running scratch code through sunxi-fel is a viable route too :)
<apritzel> so having this in sunxi-fel is better
<apritzel> but another use case would be some socinfo binary, which could live on an SD card
<apritzel> which dump this information on the UART
<apritzel> plus a lot more
<apritzel> it could check for a SPI flash, for instance, print its size, etc
vagrantc has joined #linux-sunxi
<apritzel> this could be a precursor for some generic Allwinner firmware thingie
<apritzel> the idea: having an SD card image which boots and programs the NOR flash
<apritzel> this could be as generic as possible, loading the actual firmware image from SD
<apritzel> so it detects the SoC, loads the proper image and writes it into the flash
mzki has quit [Ping timeout: 245 seconds]
<NiteHawk> apritzel: obviously we have a number of different uses cases there, ranging from very basic tasks/diagnostics (porting to new SoC), over hw info and feature detection, up to "high level" tasks possibly requiring a function library. for the latter it might also be worth to check on u-boot's "baremetal" api?
<apritzel> NiteHawk: yes, U-Boot sounds like a decent choice
<apritzel> but:
<apritzel> currently the SPL supports only one particular SoC (even board, possibly)
<apritzel> because of #ifdef hell
<apritzel> I wonder if we could either use the SPL, converting the #ifdefs into runtime socid dependent choices
<apritzel> or work our way up from uart0-helloworld, possibly pulling in the MMC driver from U-Boot
<apritzel> anyway, nothing for today, I was just curious whether anyone was looking into this already
<apritzel> I guess that's going into the same direction as ssvb's sunxi-bootsetup thing
<NiteHawk> ah, okay - so your focus would be more on an "universal" binary that would detect (and adapt to) SoCs at 'runtime'?
<apritzel> NiteHawk: yes
nikre has joined #linux-sunxi
<apritzel> the first real usecase would be a NOR flash utility
<apritzel> just one image to rule them all
mzki has joined #linux-sunxi
<apritzel> at least all which can be booted from NOR flash
dr1337_ has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
<apritzel> anyway: back to my U-Boot patches ...
Ntemis has joined #linux-sunxi
<Ntemis> hello
<Ntemis> any devs around?
<willmore> jelle, why would you want the A64 over the H5?
<Ntemis> i was looking at some hw options and it seems orange pi pc and is using wrong and less memory freq
<Ntemis> and in fex is set as mono but is dual channel 512+512
<Ntemis> right now is set at 624
<Ntemis> it should be at 667 at least
<Ntemis> in my pdf it needs 1.35v as is a ddr3L
<Ntemis> CAS Latency 11
<Ntemis> tCK(min) 1.25
<Ntemis> tRCD(min) 13.75
<Ntemis> tRP(min)13.75
<tkaiser> Ntemis: http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit -- that's why it's set to 624 MHz, since silent data corruption isn't that great
<Ntemis> tkaiser: is 667 tested?
<tkaiser> Ntemis: Can you click on URLs?
<Ntemis> i saw that table and still they use wrong freqs
<Ntemis> on 667 it can do 9-9-9
<NiteHawk> you are aware that the clock granularity on these devices is 24mhz?
<Ntemis> imo it should at least be set on that freq as minimum
nikre has quit [Remote host closed the connection]
utente_ has quit [Ping timeout: 260 seconds]
<Ntemis> NiteHawk: ah i see now, ty it was something i wasnt aware
iamfrankenstein has quit [Quit: iamfrankenstein]
<Ntemis> ah thats why the 672
utente_ has joined #linux-sunxi
<Ntemis> still in fex is set as mono but we have dual channel memory modules
<tkaiser> Ntemis: Which OS image and which kernel are you using?
reinforce has quit [Quit: Leaving.]
<Ntemis> your teams excellent armbian what else there is?
<Ntemis> am working on lakka port with kivutar and am trying to optimize the hardware
<tkaiser> Ntemis: Then DRAM initialization happens in u-boot and fex settings are only used if/when throttling occurs.
<Ntemis> for all opis
<Ntemis> hmm ok
<Ntemis> i"ll have a look
<tkaiser> Ntemis: And AFAIK the only setting then used is frequency so in case throttling occurs the kernel adjust DRAM clockspeed to the fex value.
<Ntemis> still 624 is a weird value
<Ntemis> did anyone try 816?
<Ntemis> with the correct parameters
IgorPec has quit [Ping timeout: 246 seconds]
<Ntemis> looks within ram spec better than 624
<Ntemis> here is the pdf
<Ntemis> that pdf spec applies to pipc
<tkaiser> Ntemis: Maybe you should also consider the DRAM controller inside the SoC?
<tkaiser> Ntemis: I don't know whether you've to support the software you're developing. In case you love bug reports about your software running unstable simply increase DRAM clockspeeds. Works 100 percent reliable to decrease reliability ;)
<Ntemis> :)
<Ntemis> turns pi's into a game console
<Ntemis> is voltage fed ok? at 1.35v as it wants the ram
<Ntemis> maybe less is given? am just asking for possible causes
<tkaiser> Ntemis: You should test with lima-memtester since this applies already perfectly to your use case: making use of GPU acceleration. And then you'll see how far you get with DRAM clocked above 624 MHz if you've enough samples to test through.
<Ntemis> because ram can do those speeds no sweat
<Ntemis> what am thinking is no rams fault
<Ntemis> is maybe either wrongly set up with wrong values or not given enough juice to perform
<apritzel> Ntemis: I think what tkaiser wants to tell you: there is more than the actual DRAM chip to consider
<tkaiser> Ntemis: Just use lima-memtester.
<apritzel> thinks like stability of voltage supply, DRAM controller quality, PCB routing, actual DRAM silicon quality
<Ntemis> i think problem lies in the first- stability of voltage supply
<Ntemis> can it fed 1.35v stably
<tkaiser> Ntemis: use a multimeter, there are test points IIRC
<Ntemis> no one did it?
<tkaiser> Ntemis: and after wasting a few days of your life you will end up there where linux-sunxi community currently is: Safe 624 MHz
<tkaiser> Ntemis: Sure, all this already happened. Good luck doing it again ;)
<Ntemis> hmm
<Ntemis> i sure hope h5 gets a better design then
<ssvb> tkaiser: and it would be the best case scenario
<apritzel> Ntemis: what are you actually after: gaining 6.89% of theoretical DRAM bandwidth?
<Ntemis> 624 vs 800
<Ntemis> in a dream world as it seems by tkaiser
<tkaiser> Ntemis: The hypothetical 800 being result of a value printed in a spec sheet?
<ssvb> tkaiser: a worse scenario would be Ntemis bumping the DRAM clock speed to 672MHz (or whatever), then making some SD card image of some distro and spreading it around ;-)
utente_ has quit [Ping timeout: 256 seconds]
<Ntemis> if it was stable why not
<Ntemis> but weird soc dram controller
<ssvb> and of course people would think that they are doing the right things, but the allwinner hardware is crap
<Ntemis> aha
<apritzel> Ntemis: as tkaiser tells you: it's not stable
<Ntemis> i hope h5 gets a better dram controller
<Ntemis> do you guys know if it had an update
<apritzel> I think there are rumours that those cheap SoCs get the DRAM chips from the bin ;-)
<Ntemis> ahahaa
<apritzel> (as in being sorted out by Samsung)
<tkaiser> Ntemis: It might be on some boards but not on others. And it's not 'weird' but you're dealing here with ultra cheap hardware that needs sane defaults (that's what community does and not Allwinner)
<apritzel> I am afraid this isn't so funny after all ...
<ssvb> Ntemis: DRAM reliability heavily depends on the length and impedance matching of the traces between the SoC and DRAM on the PCB
<Ntemis> amd talking about h5 getting a newer that sun9i generation dram controller
<ssvb> that's the number one reason for memory corruption problems
<apritzel> Ntemis: do you have any info on the H5 controller
<Ntemis> no tkaiser has
<Ntemis> :p
<apritzel> because I am just stuck with libdram again for the H5 U-Boot
<ssvb> lol
<Ntemis> i see :(
<apritzel> and Allwinner managed to change the boot0 loading scheme, so that boot0img doesn't work out of the box
<apritzel> and I am not sure I want to waste my time in hacking this again
<Ntemis> yeah i feel you
<ssvb> welcome to the club
<Ntemis> still the best hardware < money can buy
* ssvb had exactly the same feeling about a64
<tkaiser> Could there be something interesting on the provided Android image for H5?
<apritzel> tkaiser: MoeIcenowy put the first 50MB somewhere
<Ntemis> maybe a h3 port
<apritzel> tkaiser: I extracted the DRAM parameters
jernej has quit [Ping timeout: 256 seconds]
<apritzel> tkaiser: also the rest of that firmware stuff is there, but the layout is different from the A64 one
<apritzel> so I have a libdram based U-Boot working, but it's not redistributable, unfortunately
<apritzel> (though you can build it yourself)
<apritzel> I will push something later tonight
<ssvb> Ntemis: DRAM controllers used by Allwinner SoCs are actually decent (they are not designed by Allinnwer, but licensed), and I'm not sure what you are complaining about
<Ntemis> am complaining that i cant use jedec specs on the soc
<Ntemis> and thats a big fail
<ssvb> if you do a shitty PCB routing, then neither the DRAM controller nor the DRAM chips are at fault
<Ntemis> +1 one that one
<Ntemis> shame though
<ssvb> about jedec specs, do you mean that you would prefer to use 528MHz for DRAM?
<ssvb> just to make it closer to the standard jedec bin
<Ntemis> 533
<Ntemis> but no i wanted to go up because ram can do 800
<ssvb> 24mhz clock speed granularity, suck it up
<Ntemis> <ssvb> Ntemis: DRAM controllers used by Allwinner SoCs are actually decent
<Ntemis> the whole community suck it up at it seems
<ssvb> what about the PCB routing quality is not clear for you?
<Ntemis> fact?
<ssvb> what fact?
<Ntemis> that the routing is the fault here
<tkaiser> Ntemis: How much does an Orange Pi One costs?
<ssvb> this page provides some explanations
<ssvb> we did quite an extensive reverse engineering of the A10/20 DRAM controller in the past and know how it works and what affects reliability
<ssvb> H3 is newer, but the basic principles are all the same
<Ntemis> did anyone force the uboot to give a stable 1.35v to the ram
<ssvb> on which board?
<Ntemis> pipc
<Ntemis> or even a 1.40
<Ntemis> that is a safe mark
<ssvb> how do you imagine this? opipc has only one programmable voltage regulator, and it is used for the cpu core voltage
<Ntemis> ha
<tkaiser> Ntemis: And it gets boring, before trying to overclock anything you should maybe become familiar with the basics. It's absolutely irrelevant what's written in specs here and there, what matters is reality. And expecting wonders with $10 devices is... somewhat strange
<Ntemis> thats the issue here
<Ntemis> looks like it only takes 1.2v
<Ntemis> it needs a hardware mod
<Ntemis> thanks for the prints
<Ntemis> now is clear
<ssvb> do you have a proof?
<Ntemis> yes
<ssvb> sorry, but seems like you are talking bullshit
<ssvb> you can take the board and measure voltages yourself, there are some test points on it
<ssvb> please do this before going on a speculation rampage here
<Ntemis> what rampage? is printed clearly 1.2V/1A
<apritzel> Ntemis: in the first page only
<NiteHawk> ssvb: are you okay with cherry-picking the revised 6457c36 and 8640291? (leaving aside the third commit for now) i'll also rebase the windows branch to get the new README in asap
<apritzel> Ntemis: check page 7: Power
<apritzel> Ntemis: welcome to the world of Allwinner based SoCs: the documentation does not always hold up to the promise ;-)
<Ntemis> yeah
<Ntemis> :D
<tkaiser> Ntemis: please accept that you can measure these voltages, that people already did that and that there are some variations to take care of. And then you end up at 624 MHz
<tkaiser> Ntemis: And please stop blaming everyone/everything around. This is el cheapo hardware and compromises are needed. It's OBVIOUS!
<apritzel> you get what you pay for
<Ntemis> what the...am not blaming anyone
<Ntemis> i repsect your work guys
<Ntemis> *respect
<tkaiser> apritzel: Exactly. And your only chance is to deal with that and choose sane defaults. Or you get 'great feedback'
<tkaiser> And to be honest: you get a lot for this little money you spend on H3 hardware
<Ntemis> they could end up with a cheaper memory
<tkaiser> (same with A64 and H5 now)
<Ntemis> like a 1333
<tkaiser> Ntemis: Since people then don't fool themselves thinking only about spec sheets?
<Ntemis> oh well it worth a shot
<Ntemis> thanks guys it was enlighting
<ssvb> what kind of cheaper memory? DDR3-1333 is getting obsolete
<ssvb> because, you know, the PC market wants higher speed chips
<Ntemis> :)
<tkaiser> Ntemis: You can be assured that there *IS* already the cheapest type of memory on these boards. Since it's all about *cheap* anyway
<ssvb> that's why the arm devboard designers have no other choice, but are forced to use DDR3-1600 chips
<Ntemis> those memories are used in a router
<Ntemis> so i would call them cheap or unstable
<ssvb> but it is not a problem, because these faster chips are also compatible with slower clock speeds too
<ssvb> just check the specs of the ddr3 chips in question
<Ntemis> i did
<willmore> Are the clocks for the DRAM on allwinner chips the transfer rate or the base clocks (1/2 the transfer rate)? I'm so used to the way the PC specs only the transfer rate and never the actual clocks.
<ssvb> it's double data rate
<willmore> Understood.
<ssvb> when you see the MHz rating, it's the clock speed
<willmore> Okay, so the transfer rate is 2x that. Good.
<Ntemis> thats why i insisted on 667
<Ntemis> because that would give us 1333
<willmore> Which is not divisible by 24
<Ntemis> nope but i didnt know that
<Ntemis> at that time
<ssvb> when you see the MT/s rating, that's the transfer speed (twice higher than MHz)
<willmore> ssvb, understood.
<apritzel> willmore: but it's 32-bit single channel only - in case you wanted to compare this to your 15 year old PC ;-)
<ssvb> some people confuse MT/s and MHz
<willmore> So, the next lower multiple from 667 is 648.
<willmore> apritzel, Roger.
<willmore> ssvb, completely agreed. They even spec transfer rates in MHz which just kills me.
<willmore> I don't know how many times I've been driven half crazy by people who complain about latency increases on faster memory and how that will "kill performance".
<willmore> Uhhh, if you multiple the cycle time (1/the clock speed) with the cycles you will often see that the actual latency--measured in seconds--is less with the faster memory.
<willmore> Because: math
<ssvb> latency is a tricky thing, it does not depend just on the dram timings
<ssvb> because the dram controller is buffering the requests and can reorder them
<apritzel> has anyone actually ever checked how much influence increased DRAM speed has on the whole system performance?
<apritzel> apart from it crashing much faster :-D
<tkaiser> BTW: Below 408 MHz DRAM clock on H3/H2+ it's 12 MHz steps. I don't know why this works but it works. With BSP kernel DRAM clockspeed can be set from userspace and I tested through 132-672 MHz a while ago
<apritzel> I'd guess that it's not worth the trouble ...
<tkaiser> apritzel: Did today a test with Orange Pi Zero and 408 MHz DRAM clockspeed and USB disk throughput. 1 MB/s less compared to 624 MHz.
<ssvb> apritzel: yes, of course, you can check the table at the bottom of http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-of-the-allwinner-a10.html
<apritzel> tkaiser: this is due to the rather weird way the PLL clocks are set up
<NiteHawk> 408=24*17
<ssvb> apritzel: and for synthetic benchmarks - https://linux-sunxi.org/A10_DRAM_Controller_Performance
<apritzel> tkaiser: the DDR frequency is: (24 MHz * N * K) / M
<ssvb> in fact you can ask exactly the same question about the CPU clock speed :-)
<ssvb> has anyone actually ever checked how much influence increased CPU speed has on the whole system performance?
<ssvb> apart from it crashing much faster :-D
<apritzel> tkaiser: with all kind of constraints
<apritzel> ssvb: sure, that would have been my next question ;-)
<apritzel> I don't care so much about performance of those SBCs anyway, if I want something fast I use something else
<tkaiser> apritzel: Exactly
<ssvb> basically, fast DRAM is mostly needed for graphics
<apritzel> ssvb: what is graphics? :-D
<ssvb> because such things as scrolling are nothing else but simple memmove :-)
<ssvb> if you speed up memmove, then you get more fps for scrolling
<ssvb> well, these little boards can also run a somewhat usable linux desktop
<ssvb> you can buy a Raspberry Pi board and check this yourself ;-)
<ssvb> because children, education, learning, ...
<buZz> i used a A20 as desktop for some time, quite snappy
<apritzel> ssvb: I have some PIs and have been using them with X11
<apritzel> ssvb: actually to read the A64 user manual last christmas ;-)
<vagrantc> i hope you had a nice pipe of tobacco and a fireplace to go along with your seasonal reading
<apritzel> ssvb: any my children always look at me with pity when I try some of those boards on them ;-)
<ssvb> one of the worst performance killers for the linux desktop on these boards is the "ondemand" cpufreq governor
<apritzel> and go back to their Lenovo's and tablets ...
<ssvb> this ondemand thing does miracles and makes everything very laggy :-)
<apritzel> vagrantc: I didn't read it aloud, if you meant that
<vagrantc> apritzel: i hadn't but now i wish you had
<ssvb> but of course, people attribute this slowness to "bad graphics drivers"
<ssvb> just because graphics drivers are traditionally the number one thing to blame, nobody cares to run tests or benchmarks to figure out why their system is so slow
<apritzel> vagrantc: though those manual contain a good share of fairy tale :-D
<apritzel> ssvb: yeah, "performance" is a damn complex thing
<vagrantc> and then the ghost of dram timing cast a curse...
<apritzel> ssvb: people then try to compile with -O3 to improve things ...
<vagrantc> moar speeds now!
<apritzel> Once there were three little MMC controllers
<ssvb> well, the performance critical code paths are implemented in assembly anyway
<apritzel> one of them thought he was better (because of HS400)
<ssvb> and the CPU with the help of the NEON unit can crunch more pixels than the DRAM controller is able to serve
<apritzel> ssvb: don'
<apritzel> t tell me ...
<tkaiser> ssvb: Have you ever encountered the 'fantasy' cpufreq governor?
<apritzel> tkaiser: is that the lost sibling of the "random" governor?
<tkaiser> apritzel: No idea, but it was the active one on the first OS images for the 'real' Banana Pi. Showing lower scores when running on both CPU cores than on one. And everyone blamed the hardware back then.
<tkaiser> apritzel: So results were somewhat predictable but not in the usual way ;)
<apritzel> tkaiser: BogoMIPS has all the truth, you know ;-)
<Ntemis> what enabling CONFIG_CPU_FREQ_GOV_AUTO_HOTPLUG does?
<Ntemis> and switching to Slub is a good idea or not?
<Ntemis> note that i already enabled performance gov as we are using the soc as a console for gaming
<Ntemis> do i need CONFIG_CPU_FREQ_GOV_AUTO_HOTPLUG on performance gov?
<Ntemis> anyone?
Mr__Anderson has quit [Remote host closed the connection]
<apritzel> grep returns empty on that in 4.9-rc, so no clue ...
<tkaiser> Ntemis: You're dealing with a smelly Android 3.4.x kernel no one here is interested in. Here mainlining happens that means writing stuff from scratch to overcome the Android kernel. So I fear you're on your own.
<Ntemis> i see
<Ntemis> ty anw
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<tkaiser> Ntemis: Instead of wasting time with this CPU stuff you might try out to get a newer Mali400 driver variant up and running. The one Armbian uses is quite old (3 or 4) and it might be possible to use 6.0. But I've to admit that I'm pretty much clueless regarding everything related to display.
<Ntemis> is r4p0
<Ntemis> i can update the driver but i need blobs that i dont have
<Ntemis> and no where to be found either
<tkaiser> Your use case could benefit from high memory bandwidth (not possible to increase values since you introduce instabilities then) and GPU performance. So I would focus on the latter and don't forget to benchmark regularly.
<Ntemis> wtf THANK YOU!
<tkaiser> But no idea whether those are ok (framebuffer vs. X11)
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<Ntemis> will test
vagrantc has quit [Quit: leaving]
bugzc has joined #linux-sunxi
<Ntemis> hmm interesting
<Ntemis> new alwinner r8 and r16 series will have the same gpu as h3 :D
<Ntemis> so h3 can benefit from newer mali blobs
<Ntemis> perfect
perr has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
The_Loko has quit [Quit: Leaving]
paulk-collins has quit [Quit: Leaving]