<vishnup_>
wens: mripard: will you mind having a prediv_table for ahb1 clock, adapting current implementation and having two separate setup functions for two compatibles
<KotCzarny>
nah, as long it doesnt overheat or gets too hot im fine
<KotCzarny>
but apparently one of my usb ports is not working
<tkaiser>
Check the 1st pinned Debian thread in Orange Pi forums and follow the steps there
<tkaiser>
If you're using an OS image from loboris then this will fix all issues except overvolting. You then have to apply the 'thermal fix' again
<KotCzarny>
yes, im using loboris jessie-xfce image
<tkaiser>
Then all you need is written where you got the images from. It's just a script that will replace script.bin and kernel based on the OPi model you have.
<KotCzarny>
uhum
<tkaiser>
Just read and apply the fixes.
<tkaiser>
Currently you use script.bin for Orange Pi Plus therefore USB isn't working. Loboris also uses different kernel binaries for the various H3 based Orange Pi (maybe not necessary). Just follow the steps outlined there
<KotCzarny>
also, is chromium recommended browser? it seems snappy enough
<KotCzarny>
tkaiser, usb is working, from 3 usb ports 2 work (1 single, and 1 of the dual connector)
<KotCzarny>
might be some physical issue
<tkaiser>
No idea, my Orange Pi PC is running 4.4.0-rc5. And one last time: READ what's written there and this will fix it. Just do it and stop explaining... ;)
<KotCzarny>
:)
<KotCzarny>
btw. does sound work with 4.4?
<KotCzarny>
hmm
<KotCzarny>
but that debian sticky is for opi, not opipc
<apritzel>
yeah, that matches the pins on the connector
mozzwald has quit [Quit: leaving]
<tkaiser>
KotCzarny: ODROID C1+ happily clocks with up to 1.7GHz. Hardkernel uses a huge heatsink for S805
<KotCzarny>
do they have to overvolt it much?
<tkaiser>
No idea. I ran stress and sysbench for a few hours and temperature was ok
mozzwald has joined #linux-sunxi
<tkaiser>
apritzel: At which clockspeed is your Pine64 currently running when you use 4.4?
<apritzel>
actually no idea, BogoMips says 48 :-D
<apritzel>
(but that's derived from the timer frequency ...)
<apritzel>
let me check if there is something in the logs
mozzwald has quit [Quit: leaving]
popolon has quit [Ping timeout: 255 seconds]
mozzwald has joined #linux-sunxi
<apritzel>
tkaiser: doesn't seem to say in the logs, but PLL6 is 600 MHz, which smells like it's running at the advertised 1.2 GHz
<tkaiser>
The time execution of 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' would be interesting (but I fear sysbench isn't installed)
<ssvb>
apritzel: if you are curious about the CPU clock frequency, then we can measure it in an experimental way
<KotCzarny>
hmm, is dma used for gmac/sata/mmc/anything on bpi? (m1 or r1)
<ssvb>
apritzel: I really want to know if NEON in Cortex-A53 has 128-bit data path (like in Cortex-A8) or only 64-bit data path (like in Cortex-A7)
<apritzel>
ssvb: sure, but only tonight, as I don't have the device with me right now
popolon has joined #linux-sunxi
<ssvb>
apritzel: ok, thanks, this test should run either 8 seconds or 16 seconds depending on NEON performance
* ssvb
is impatiently waiting for getting his own pine64 board
<hp197>
ssvb: your not the only 1\
vishnu_ has quit [Ping timeout: 250 seconds]
vishnu_ has joined #linux-sunxi
<wens>
KotCzarny: those have their own built-in DMA engine, not using the system wide one
<KotCzarny>
wens, so even if there is no indication, reading from disk/network uses dma and not cpu only?
<wens>
i guess so? not really familiar with internals of those blocks
<KotCzarny>
because 100-200M/s from hdd and 100% cpu usage might be an indicator of dma not being used
<wens>
interesting that you're getting such high speeds
<wens>
i couldn't get my SSD to go past 70MB/s on mainline
<KotCzarny>
my wd green drive easily reaches its max ~110M/s on read
<KotCzarny>
with legacy kernel (3.4.110)
<wens>
hmm, is there something wrong with mainline's driver?
<KotCzarny>
dont ask me, im more user than kernel hacker
qt-x has quit [Quit: Leaving]
<tkaiser>
wens: Nope, kernel 4.4.0 and +160 MB/s read
<wens>
somethings wrong with my setup then :/
<KotCzarny>
:)
<tkaiser>
Olimex Lime2 + Samsung EVO 840
<KotCzarny>
bpi-r1 + wd green 3T
<wens>
or my intel ssd is busted
<KotCzarny>
wens, test in pc?
<KotCzarny>
did you offload ints onto second core?
<tkaiser>
In my setup the SSD is too slow (120 GB model is somewhat limited)
<tkaiser>
~200 MB/s read is possible with both 3.4 and mainline. But I wonder why SATA writes are limited to max. 45 MB/s
<KotCzarny>
tkaiser, bad dma? cpu waiting for some io?
<tkaiser>
I have no idea. Only searching for a possible answer. Since Nov. 2013 approx. ;)
<KotCzarny>
what is memcpy speed of a20?
<KotCzarny>
more than 200M/s ?
<tkaiser>
Sure
<KotCzarny>
then there is no/partial dma being used, which means cpu has to do more work than required
<KotCzarny>
btw. ssvb's led patch worked wonders
<tkaiser>
KotCzarny: And Ethernet still working?
<KotCzarny>
yes
<KotCzarny>
but one thing is weird with this img, only 10mbit (still better than no connectivity)
<KotCzarny>
and it was even before i patched those leds
<tkaiser>
Ok, then I did something wrong back then. Will edit wiki page now
<KotCzarny>
maybe you've applied some more patches/changes
<tkaiser>
Maybe something else went wrong (common problem with storage and networking ;) )
<ssvb>
tkaiser: I find it rather difficult to believe that LEDs can be related to Ethernet, but of course we can't rule anything out without doing actual tests
<tkaiser>
ssvb: yes, I think I confused something. Maybe wrong pin definition for gmac_phy_power_en. Anyway I believe I made another mistake and it's unrelated (LED <--> Ethernet PHY)
fl_0 has quit [Ping timeout: 260 seconds]
premoboss has quit [Quit: Sto andando via]
<wens>
right, i was testing write (zeroing out my SSD actually)
fl_0 has joined #linux-sunxi
<tkaiser>
wens: And you exceeded 45 MB/s?
<wens>
forgot the actual numbers
<wens>
just that it was very slow for an SSD
<tkaiser>
I never saw anyone being able to exceed 45 MB/s (cpufreq tuning) or even 40 MB/s (normal settings). Only when measured wrong (partially fs buffers)
<KotCzarny>
wens, you should use DISCARD for zeroing, much faster
afaerber has quit [Quit: Ex-Chat]
<wens>
right
<KotCzarny>
tkaiser, is your opipc connecting at gigabit link speed? mine seem to be stuck at 10mbit
<KotCzarny>
s/gigabit/100mbit/
<KotCzarny>
maybe the cable is bad, oh well, gonna investigate tomorrow
<tkaiser>
It's Fast Ethernet only since it's using the H3's internal PHY
<tkaiser>
Only the Plus (2) uses an external PHY (the usual RTL8211) and is GbE capable
<KotCzarny>
link partner: 10baseT-FD 10baseT-HD flow-control
<KotCzarny>
hrm
<tkaiser>
Yes, but it's running with 4.4.0-rc5 therefore using USB-Ethernet
<KotCzarny>
so you dont use onboard one?
<tkaiser>
IIRC onboard negotiated with 100 Mbits/sec using 3.4.39
<KotCzarny>
uhum
ojn has quit []
<tkaiser>
Nope, I don't since there's still no mainline kernel driver for the new Ethernet implementation in H3/A83T/A64
ojn has joined #linux-sunxi
<KotCzarny>
im stuck with legacy then for now, still, it works, boots fine, doesnt overheat, and chmromium seems to be working much more nicely than firefox/iceweasel on armbian (bpi-m1)
<wens>
apritzel: fyi the remix mini has no screws, so i'm likely to destroy the case taking it apart :|
<wens>
tkaiser: so you're running off usb?
<KotCzarny>
wens: hope your using doesnt have self-destroy apparatus inside :>
<KotCzarny>
s/using/unit/
<apritzel>
wens: please don't do it ;-)
<apritzel>
wens: I was actually just wondering whether it can boot of an microSD card
<apritzel>
or whether they wired the eMMC to MMC0 and let the BROM try that first
<tkaiser>
wens: Yes, when the 1st patches arrived for USB I tested it and made the mistake to build a NAS hosting music. Now I can't switch it off.
pietrush` is now known as pietrushnic`away
pietrushnic`away is now known as pietrushnic
<tkaiser>
apritzel: And how to recover from a bricked Remix Mini?
<apritzel>
tkaiser: FEL?
<apritzel>
tkaiser: or send it back for recovery?
<KotCzarny>
send to manufacturer for replacement? ;)
<apritzel>
I was just wondering because this whole Remix things sound like more about the software to me
<tkaiser>
True, it seems they really care about 'user experience'
<KotCzarny>
user experience as long user is not a hacker
<tkaiser>
In case you could provide your SD card image wens could try it out ;)
<apritzel>
so some of the A53 Rockchip TV boxes for instances had locked firmware
<apritzel>
tkaiser: good point, will try my best ...
hipboi has quit [Quit: This computer has gone to sleep]
<wens>
apritzel: no uart, so you can't really tell if it came up or not?
<apritzel>
ah, forgot about that
<apritzel>
now you wanting to open the case makes sense ;-)
<apritzel>
in case anyone wonders: BL3-1 is ARM trusted firmware lingo for the runtime parts of the firmware, mostly providing the PSCI service
<tkaiser>
apritzel: Maybe a silly question: But how do you modified the initramfs?
<wigyori>
apritzel: nice one
viccuad has joined #linux-sunxi
<apritzel>
In this case there is none, the kernel has everything compiled in and Ubuntu Core starts directly
<apritzel>
tkaiser: ^^^
<apritzel>
for the initial boot without MMC I took a Debian installer initrd, modified it and put it in the same Android image as the kernel (with mkbootimg)
<apritzel>
tkaiser: or do you want to know how to modify an initramfs?
<tkaiser>
Nope, the mkbootimg part is the one I was interested in :)
<apritzel>
I flashed the resulting image into one of the free Android partitions ("misc" in this case)
jjwerner has joined #linux-sunxi
<apritzel>
since those partitions are the only thing that this crippled u-boot understands
Deskwizard has quit [Read error: Connection reset by peer]
<apritzel>
the mmc command is there, but does not work
diego_r has quit [Ping timeout: 240 seconds]
<jjwerner>
hey apritzel, great job on getting 4.4 up. I should be getting my pine in coming days, do you have some testing / easy tasks that I could help with?
Deskwizard has joined #linux-sunxi
<apritzel>
jjwerner: I guess we need some testing for the new Ethernet driver
<apritzel>
montjoie sent me his alpha version, which I will try later tonight
<apritzel>
I will try to publish an image today or tomorrow
<jjwerner>
my board is on the way from ny to nc, I've been lurking on irc logs and looking at the patches. I have decent kernel background and basic understanding of arm soc booting :)
_massi has quit [Remote host closed the connection]
<apritzel>
jjwerner: do you want to take a look at the regulator?
<apritzel>
it's an AXP803
<apritzel>
similar to the AXP209 which is already supported
<apritzel>
and even close the AXP806/809, for which patches are floating around(?)
<jjwerner>
sure, I guess I will have to start learning quickly ;)
<apritzel>
jjwerner: so did I the past days ;-)
<apritzel>
Documentation/power/regulator is your friend
<apritzel>
also drivers/regulator/axp20x-regulator.c
<apritzel>
read it, sleep over it, read it again ;-)
<jjwerner>
sleep is overrated :P
nove has joined #linux-sunxi
<montjoie>
does someone with the a83t homlet could confirm that it boots from nand without network/dhcp ? (I need to know which PHY it have)
arossdotme-planb has quit [Ping timeout: 265 seconds]
<jjwerner>
@apritzel: nope i haven't I'll check irc logs
mzki has joined #linux-sunxi
<ssvb>
KotCzarny: what are you going to do with mali?
<montjoie>
Could someone help me with pinctrl, I try to test RGMII on a83T but I dont understand how pinctrl works
<KotCzarny>
ssvb: accelerate browser? (apparently some users used it for chromium)
<ssvb>
KotCzarny: do you have a link?
<KotCzarny>
closed the page, but i've copypasted cmdline: chromium-browser --ignore-gpu-blacklist --force-gpu-rasterization --use-gl=egl
<KotCzarny>
(just to ease future searches)
<ssvb>
so basically, the idea is that you have a normal chromium package and when you run it with certain command line options, it gets a huge performance boosts?
<KotCzarny>
dont know, user had some errors
<ssvb>
oh, it was not a success story then
<KotCzarny>
but noted it in case it does anything (will test on bpi tomorrow)
<ssvb>
thanks, we should probably have a list of prominent use cases for the gles drivers described somewhere in the wiki
<ssvb>
people are free to contribute to collecting such information
<KotCzarny>
ssvb, if you have working gles you can probably try running chromium and see if it makes a difference
<KotCzarny>
so apparently it does accelerate rendering
ricardocrudo has joined #linux-sunxi
<KotCzarny>
see: chrome://gpu page to see if it actually is enabled
vishnup has quit [Quit: Connection closed for inactivity]
soderstrom has quit [Ping timeout: 276 seconds]
<catphish>
would someone be able to point me to where in the sunxi source code i might be able to find the code that invalidates all the cpu caches, and enables them?
<catphish>
specifically i am trying to replicate this behaviour on sun7i
<KotCzarny>
another interesting param: --num-raster-threads=2
<apritzel>
catphish: that is a big topic ;-)
<catphish>
apritzel: oh dear, i succeeded in building a page table and enabling my MMU, but it actually significantly reduced performance, after a lot of reading i decided this was because the caches weren't invalidated and hence weren't being used
<catphish>
but im struggling to find an example of how to better initialize the caches
<catphish>
was hoping linux-sunxi might do it, and i could copy/paste somethingf
<apritzel>
better look into arch/arm in the kernel
<KotCzarny>
ssvb: another flag: --gpu-no-context-lost
<apritzel>
catphish: specifically v7 code is what you are looking for
<catphish>
thanks, i'll look there
<apritzel>
caches are a core thing, not SoC specific, so it's mostly architectural here
<apritzel>
arch/arm/mm/cache-v7.S for instance
<apritzel>
don't you dare to look at the older stuff ;-)
<apritzel>
or in those mach-xxx directories
<catphish>
would it be standard across ARMv7 then?
<catphish>
cache-v7.S seems like the right thing :)
<apritzel>
yes
<catphish>
looks hard
yann|work has joined #linux-sunxi
<apritzel>
you have no idea ;-)
<catphish>
i was hoping i could just call the helpfully named "Invalidate both instruction and data caches or unified cache (flush branch target cache, if applicable)"
<catphish>
it turns out you can't
<catphish>
hopefully the linux examples will make some sense of it
<ssvb>
if you set some page as "strongly ordered", then the performance will be very bad
<apritzel>
catphish: if you are lucky, maz_ is around to answer your questions afterwards ;-)
<catphish>
ssvb: actually i think the reason is that by disabling and re-enabling the MMU, i have made a mess of the caches, i suspect the i-cache was working before but now isn't
oliv3r has joined #linux-sunxi
<ssvb>
catphish: what kind of page attributes are you using now?
<catphish>
ssvb: i set everything as "non shared device" except for my SRAM which i set as cacheable
<catphish>
let me double check
<ssvb>
if you have messed up cashes and have coherency problems, then your code will likely crash
<ssvb>
just running slow means that the configuration is probably not tuned for best performance
<catphish>
ssvb: interesting, i assumed it was simply refusing to start the caches
<catphish>
i'll try again and then paste the code
<ssvb>
ARM ARM has documentation about the MMU and has information about what kind of default access attributes are implied by default when the MMU is disabled
<apritzel>
catphish: take a week off to read that, then come back here ;-)
<ssvb>
you can set page attributes which are worse than these defaults :)
<catphish>
i did write this at 3am, may have missed something
jjwerner has quit [Ping timeout: 252 seconds]
soderstrom has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
iamfrankenstein1 has joined #linux-sunxi
jjwerner has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 260 seconds]
<catphish>
but its much less performy than without the MMU enable line
<catphish>
not sure if you care :)
arossdotme-planb has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
arossdotme has quit [Ping timeout: 264 seconds]
<apritzel>
catphish: you could try the usual ARM snakeoil: "dsb", possibly "isb"
<apritzel>
I guess you actually may need an isb between setting TTBR and enabling the MMU bits
fl_0 has quit [Ping timeout: 240 seconds]
* catphish
googles
<WarheadsSE>
Nice. Get busy with $dayjob a few days and some solid progress on the A64
<WarheadsSE>
Good to see guys
<WarheadsSE>
(and gals?)
fl_0 has joined #linux-sunxi
<apritzel>
WarheadsSE: you have a Pine64 too, right?
leio has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-sunxi
arossdotme has joined #linux-sunxi
arossdotme-planb has quit [Ping timeout: 256 seconds]
<WarheadsSE>
apritzel: Yes
<WarheadsSE>
But I can't really do anything with that lichee tree with Arch
<WarheadsSE>
So seeing you've got a 4.4.x running, thats a solid sign
<apritzel>
did you try to compile their kernel from the BSP?
<WarheadsSE>
Did I miss something? Is it newer than I thought?
<apritzel>
the BSP is broken and outdated
<WarheadsSE>
Right, which means it isn't going to be worth my time to make work w/ Arch Linux ARM
<apritzel>
not with that tree, at least
<jjwerner>
WarheadsSe: how about slapping arch rootfs on top of the latest binary image and see where you can get with that? that's what tkaiser was talking about in pine forums
<WarheadsSE>
Ah, I am not on the pine forums
<azend|vps>
woah
<azend|vps>
there's people in here
<WarheadsSE>
Been shoulder deep in intel graphics w/ Skylake xorg problems
<azend|vps>
there's never people in here!
<WarheadsSE>
eh
<KotCzarny>
not true
<WarheadsSE>
<.<
<KotCzarny>
azend|vps: you must be new to irc
<azend|vps>
there's never people _talking_ in here :P
<WarheadsSE>
I've been here for the better part of several years?
<azend|vps>
KotCzarny: .. no
<KotCzarny>
its a place where you leave session on, ask questions and come back for backlog in a few days
<WarheadsSE>
anyways, jjwerner I can go plink around, got any link?
leio has joined #linux-sunxi
<azend|vps>
KotCzarny: only some channels :P
<KotCzarny>
anyway, nite nite
<apritzel>
WarheadsSE: actually userland was no problem for me at all
<apritzel>
just downloaded the Ubuntu core 14.04-3 .tgz for arm64, added ttyS0.conf, populated /etc/fstab and set an empty root passwd
<WarheadsSE>
apritzel: 14.04 LTS doesn't make use of latest systemd
<WarheadsSE>
I don't expect that a 4.4.x kernel will give me any issues at all, in terms of userland
<apritzel>
I know, that's why I use it ;-)
<WarheadsSE>
but the lichee pile, yeah... no
* apritzel
runs Slackware normally ;-)
<WarheadsSE>
i grok'd by the kernel compile host
akaizen has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
mosterta has joined #linux-sunxi
avph has quit [Ping timeout: 255 seconds]
avph has joined #linux-sunxi
interrobangd_ has quit [Quit: Leaving]
soderstrom has quit [Ping timeout: 240 seconds]
viccuad has quit [Quit: WeeChat 1.3]
<catphish>
finally found the reference manual for armv7
paulk-collins has joined #linux-sunxi
mosterta has quit [Ping timeout: 245 seconds]
mnr has quit [Quit: leaving]
iamfrankenstein has quit [Quit: iamfrankenstein]
leio has quit [Ping timeout: 255 seconds]
interrobangd has joined #linux-sunxi
danboid has joined #linux-sunxi
<danboid>
Is the BananaPi IR receiver supposed to work under 4.4.0?
akaizen has joined #linux-sunxi
paulk-collins has quit [Quit: Quitte]
vagrantc has quit [Quit: leaving]
orly_owl has quit [Ping timeout: 260 seconds]
jjwerner has quit [Ping timeout: 252 seconds]
ojn_ is now known as ojn
<danboid>
The git repo for the keybinder app recommended by the wiki for using the IR receiver no longer exists
<Turl>
danboid: the bitbucket link has that info :)
<NiteHawk>
danboid: are you experiencing specific issues with the bpi IR receiver? i've tested it briefly with one of the early 4.x kernels, seemed to work back then
<danboid>
NiteHawk, Yes.
<danboid>
NiteHawk, I have a /dev/input/event0 but that appears to be a axp20x-pek which seems to be a power switch?
<danboid>
or some sort of switch from my limited research
interrobangd has quit [Quit: Leaving]
<danboid>
NiteHawk, It may just not be enabled in my kernel?
<danboid>
NiteHawk, Would youknow how I'd check my kernel config for BPi IR?
<NiteHawk>
gimme a minute, i'll boot my bpi to check it again
<danboid>
NiteHawk, Thanks!
<Turl>
danboid: make sure IR_SUNXI is enabled on your config
<danboid>
NiteHawk, Mine worked under 3.x
<danboid>
on the sunxi kernel
<NiteHawk>
iirc, handling of IR input (devices) has changed quite a bit between 3.4 and 4.x - don't take things like device names for granted
<NiteHawk>
you should probably start with checking your kernel config by grepping for IR_SUNXI - e.g. "zcat /proc/config.gz | grep IR_SUNXI"
<Turl>
it's missing MODULE_DEVICE_TABLE now that I look at it; it should autoload with that bit added
<danboid>
NiteHawk, I'm not sure if its /dev/input/event1 (sunxi-ir) or /dev/input/event2 (MCE IR Keyboard/Mouse (sunxi-ir)) that I should be using with my remote
<danboid>
I'm sure there was only the one ir input device under 3.x