<oneinsect>
but they are totally surrendered (intel) to Arm products
<oneinsect>
and they are not going to be any more low end socs
<oneinsect>
from intel
<oneinsect>
kinda of sad
<oneinsect>
but true
<orly_owl>
who cares about intel
<oneinsect>
any alternative would have been better
<oneinsect>
in the market
<orly_owl>
rockchip
<oneinsect>
i agree
<orly_owl>
idk who else there is
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
<KotCzarny>
samsung?
<KotCzarny>
:)
<KotCzarny>
quallcomm
<plaes>
do you see much upstreaming from those guys?
<KotCzarny>
xscale, marvell, freescale, broadcom
<plaes>
atmel
<plaes>
mediatek
<plaes>
isn't xscale dead?
<KotCzarny>
there is a lot of brands in the arm market
<KotCzarny>
TI, nvidia, nxp, stm
<KotCzarny>
and probably a lot of chinese brands
<plaes>
funny thing is that Google is pushing the chinese brands
<plaes>
due to chromebook (but not Android)
<orly_owl>
probably cheaper
<KotCzarny>
what is google glass based on?
<orly_owl>
also chinese brands would be much more eager to customise their chips for google
<KotCzarny>
foxconn and omap
<KotCzarny>
repeating my yesterday's question, anyone have a clue why 8188cu chip loses connectivity after some time? (due to ignoring incoming arp who-has requests, probably some sleep mode issue)
kaspter has quit [Remote host closed the connection]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<oneinsect>
do you want me to check
<oneinsect>
KotCzarny:
<oneinsect>
i have a couple of modules ...dont know if anyone is based out of 8188cu...what model is it?
<plaes>
3.4?
<plaes>
KotCzarny: in case you're on mainline try rtl8xxxu driver
<KotCzarny>
oneinsect: nah, its probably broken driver/default settings
reev has quit [Read error: Connection reset by peer]
<slapin>
KotCzarny: the android source code is source of information, I'm more interested in mainline of course
yann|work has joined #linux-sunxi
<slapin>
do anybody have mainline runnin on H3? is there any docs available for H3?
oneinsect___ has joined #linux-sunxi
<oneinsect___>
i have it
<oneinsect___>
running
<oneinsect___>
on mainline
<oneinsect___>
on nanopi m1
<oneinsect___>
H3 based
<oneinsect___>
i get i2c based rtc clock
<oneinsect___>
wifi working
<oneinsect___>
ethernet as well
<oneinsect___>
i use it as a server though
oneinsect has quit [Ping timeout: 250 seconds]
dlan has quit [Ping timeout: 250 seconds]
<KotCzarny>
i've never heard of using for android different kernel than allwinner's one
<KotCzarny>
oneinsect: small window again? ;)
<oneinsect___>
shucks i am so sorry
<slapin>
oneinsect___: cool, I got orangepi plus2 and want to run mainline on it
<oneinsect___>
you can run beautifully....just get yourself armbian sources and compile only a kernel and you can use any rootfs...if needed modify the config as well
<KotCzarny>
slapin: for h3 only usb is missing, which is planned for 4.7
<KotCzarny>
also, you can use whole armbian, not only kernel
<slapin>
KotCzarny: how about video decodding and encoding?
<slapin>
I plan to build OE anyway
<oneinsect___>
yes there is a crash that you see (only on one of the USBs)...when you plugin an usb ...that only in dmesg...but it should be fixed in 4.7
<oneinsect___>
there is no hardware assisted encoding...only software but it works fine for me...i get around 30 to 60 fps using a usb based dvr which sends in mjpg format
<slapin>
oneinsect___: that is fine, I plan to work on kernel anyway
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
<oneinsect___>
make a ubuntu 4.0.4 lts x64 bit kernel and get your armbian from here...its very simple
<slapin>
oneinsect___: about encoding - is there any implementation using hardware encoding?
<KotCzarny>
slapin: see cedrus page on wiki
<KotCzarny>
there is proof of code, but not implemented in vdpau yet for h3
<oneinsect___>
yes there is, although only baseline...yes cedrus...
<oneinsect___>
apt-get -y -qq install git git clone --depth 1 https://github.com/igorpecovnik/lib cp lib/compile.sh . nano compile.sh # alter if necessary
<oneinsect___>
not too hard so play around.... KotCzarny in here is the perfect human ...he made it all for me till date
<slapin>
too bad not ffmpeg-3.0
oneinsect___ has quit [Quit: Page closed]
oneinsect has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
<oneinsect>
somehow i liked gstreamer very much...gives very good low latency encoding... ffmpeg...hmmm i dont know
<slapin>
oneinsect: doesn't gstreamer use ffmpeg?
<oneinsect>
no i dont think so ...i mean there is plugin but you dont really need too
<oneinsect>
GStreamer is a broader library, and can actually use FFmpeg plugins. For simple and typical transcoding jobs, maybe FFmpeg is easier to use. But for more complex operations, GStreamer is super powerful. I have done clipping, cropping, transcoding, streaming frame extraction, and merging audio and video from different sources, all just using GStreamer command lines.
<oneinsect>
can allwinner based board really survive 24x7 operations
<oneinsect>
that is a question i always wanted to know
<orly_owl>
why not
<orly_owl>
try it and find out
<oneinsect>
hmmm
<KotCzarny>
i can say bpi-r1 does nicely for a router/server (as long one doesnt need performance, but is stable enough)
<KotCzarny>
and the reboot was because i had to do somy physical reconf in the room
<oneinsect>
i am thinking can we use some kind peltier cooling for h3 based boards? ...is it the same uptime for h3? have you had time to check?
<KotCzarny>
oneinsect: for h3 i had to solve why it was losing connection, but it's stable if you provide good power
<oneinsect>
hmmmm
<KotCzarny>
i mean, connection is because of broken realtek driver
<KotCzarny>
and if you plan to do some power computing, you should have stable power brick
<oneinsect>
ummmm
jernej has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
mossroy has joined #linux-sunxi
oneinsect has quit [Ping timeout: 250 seconds]
jernej has quit [Ping timeout: 260 seconds]
oneinsect has joined #linux-sunxi
jernej has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
paulk-collins has joined #linux-sunxi
<oneinsect>
can anyone tell me how to access tty1 on this nanopi m1 board....there are two tty0...to tty49
<oneinsect>
too many*
leio has joined #linux-sunxi
<KotCzarny>
do you mean ttyS1 ?
yann|work has joined #linux-sunxi
jbrown has quit [Quit: Leaving]
yann|work has quit [Ping timeout: 250 seconds]
jbrown has joined #linux-sunxi
jstein has joined #linux-sunxi
yann|work has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
yann|work has quit [Ping timeout: 276 seconds]
<oneinsect>
yes
<oneinsect>
thanks
<oneinsect>
found it
iamfrankenstein has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
willmore: A53 crypto extensions> I know it's optional, I just doubt that many SoC vendors disable it
<KotCzarny>
moneys?
<apritzel>
willmore: I guess the reason for the configurability is to avoid possible export regulations
jstein has quit [Remote host closed the connection]
<apritzel>
KotCzarny: that's the point: it's an configure option, not a license option - you pay the same with or without it
<KotCzarny>
ahm
<apritzel>
and I guess by not configuring it you just set a bit in the core which denies execution
<apritzel>
so you don't even save silicon area
staplr has quit [Ping timeout: 276 seconds]
<oneinsect>
i see so many in the list of people in this room....how come most are so silent
<KotCzarny>
you are new to irc, aren't you?
<oneinsect>
yes
leio has quit [Ping timeout: 260 seconds]
Netlynx has joined #linux-sunxi
<plaes>
who's that cmuelle guy in wiki?
oneinsect has quit [Ping timeout: 250 seconds]
<NiteHawk>
conan the barbarian? :)
oneinsect has joined #linux-sunxi
<plaes>
dunno, he is dumping lots of data to his device page that doesn't belong there
<NiteHawk>
that's the barbaric part...
<NiteHawk>
:P
<NiteHawk>
and yes, i agree - it's annoying
oneinsect_ has joined #linux-sunxi
oneinsect has quit [Ping timeout: 250 seconds]
<KotCzarny>
plaes, nitehawk, let him/her
<KotCzarny>
at least its all contained into one page and not over the wiki ;)
<KotCzarny>
ahm, (+156,300) ? lol
<KotCzarny>
ok, you are right ;)
<NiteHawk>
well, there's a reason we have rules / a common structure for device pages; so that users can find their way around. those rules can be bent a little, but you should put some thought/effort in how to present your information. stuff that's clearly doesn't belong to a device page (or tends to simply render it unreadable) should go to subpages or has to be kept externally
staplr has joined #linux-sunxi
<KotCzarny>
but you have to admit he is thorough
<KotCzarny>
quite a bit of info and tricks
<NiteHawk>
i'm not saying it's all useless. it just needs to be sorted and presented nicely somehow...
<KotCzarny>
offtopic, anyone know how long build-dh takes on a20? already 120+ minutes o.o
<KotCzarny>
maybe you should send him pm?
<plaes>
I'll be offline from now on.. until tomorrow evening..
<KotCzarny>
hmm, can i set h3 to 1296mhz? somehow this freq is missing from the list
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
<NiteHawk>
KotCzarny: with mainline kernel? you'll probably need to tweak the dvfs operation points in the DTS. i've done similar to "overclock" my bpi back to 1008MHz
<KotCzarny>
nitehawk, legacy
<NiteHawk>
hmm... i think that's in the fex then?
<KotCzarny>
set thingies to that value, but its ignored
<KotCzarny>
maybe there is some hardcoded list of possible values in kernel?
<NiteHawk>
i think is has to be a multiple of the base clock, but your 1296 looks sane in that regard (48MHz * 27)
<KotCzarny>
yes, somehow next value is 1344
<NiteHawk>
does it simply get ignore?
<NiteHawk>
+d
<KotCzarny>
nope, it looks like its not a valid speed
<KotCzarny>
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state doesnt list it
<NiteHawk>
no idea then, sorry. maybe you could cross-check the value with the mainline kernel (to see if it behaves the same)?
<NiteHawk>
ssvb: is there a good reason that sunxi-fel uses "static int timeout = 60000;"? 60 seconds seems a long time to wait before a timeout is reported back to the user, i'd think 10 secs would work just as well
<ssvb>
NiteHawk: I think we were hitting this timeout with large chunk sizes and slow FEL transfer speed
<NiteHawk>
ssvb: that is with max chunk size (AW_USB_MAX_BULK_SEND), i assume? at least that sounds plausible
<ssvb>
yes
<NiteHawk>
k, that's a valid argument not to touch that value. thx!
<ssvb>
or reduce the AW_USB_MAX_BULK_SEND size
<ssvb>
you can do some experiments with it
<NiteHawk>
we're doing it for the progress display anyway...
<NiteHawk>
might as well get rid of that and always chunk at 128K - that's small enough to be well below any reasonable timeout
<KotCzarny>
./build-dh just hit 4h mark
<KotCzarny>
o.o
<KotCzarny>
oh my poor banana
tipo has joined #linux-sunxi
gzamboni has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
scream has joined #linux-sunxi
afaerber has joined #linux-sunxi
<NiteHawk>
ssvb: can you tell if the current 4 MiB AW_USB_MAX_BULK_SEND is a hardware- or protocol-imposed maximum?
<montjoie>
just updated my github with the latest h3 emac driver
cnxsoft has quit [Quit: cnxsoft]
<ssvb>
NiteHawk: most likely something protocol-imposed, still you can adjust this timeout until it fails and then compare it with the transfer speed multiplied by the chunk size
<ssvb>
NiteHawk: or maybe something in libusb
<NiteHawk>
ssvb: i intend to lower it, but would like to document if the previous value was an 'absolute' limit. or just leave that to "git blame"?
<ssvb>
NiteHawk: err, chunk size divided by the transfer speed
<ssvb>
NiteHawk: it is not an absolute limit, we just push a buffer of data into libusb and expect it to be processed in a reasonable time
<NiteHawk>
yes - i'm targetting 1 MiB chunk at "slow" transfers of ~128KiB/s, so they can be expected to be 8 seconds or less - which allows for a 10 secs timeout
<NiteHawk>
sounds reasonable?
<ssvb>
NiteHawk: I would estimate really slow transfers as ~50KiB/s
<NiteHawk>
oh. the current SoC support table lists non-MMU transfers of around 191KiB/s...
<NiteHawk>
so i thought 128 to be on the safe side. maybe that's too optimistic
<ssvb>
NiteHawk: early tests on H3 showed only ~96KB/s transfer speeds
<NiteHawk>
ok, i'll lower my assumptions then. btw our current values won't do either with 50kB/s - 4 MiB at that speed would take over 80 seconds
<NiteHawk>
though you'd get away with the H3 96kB/s admittedly :)
leio has joined #linux-sunxi
<ssvb>
NiteHawk: ok, ~70KB/s then (4000 / 60) :-)
<NiteHawk>
i'll assume "slow" to be 64kB/s then
<ssvb>
ok
<NiteHawk>
there's still some margin - if i calculate with 8 seconds (-> 512 KiB chunk size), and the timeout is at 10, then we could still arrive in time at ~50kB/s
<NiteHawk>
putting in appropriate source comments should explain this anyway - which is much better than the current 'magic'. so it can be adjusted if needed
<tkaiser>
KotCzarny: I can't test since I've no access to my H3 devices and the Orange One I sent to Zador is lost in transit. So we need your help :)
<KotCzarny>
tkaiser, i have my own custom kernel, wont it disturb it?
<KotCzarny>
(though i can simply backup it)
<tkaiser>
KotCzarny: Please back it up and give the new one a try (then you get also 1296 MHz for free to test ;) )
<KotCzarny>
tkaiser: sources finished patching few moments ago ;) but i'll test that dpkg
<KotCzarny>
shall i install all 3 debs or just image?
<tkaiser>
All 3
<jelle>
woah
<tkaiser>
But for testing purposes whether the privileges escalation is resolved the image is already enough
<KotCzarny>
by privilege escalation you mean those sunxi_debug? ;)
<tkaiser>
Yes
<KotCzarny>
funny thing is that thing was present in all legacy kernel and no one cared/knew ;)
<KotCzarny>
till yesterday when i stumbled upon it accidentally
<tkaiser>
KotCzarny: Seems to only affect the newer 3.4 BSP variant for sun8i. I've opened issues at cubietech and linksprite already and might do as well with SinoVoip (useless, they never fix anything)
<KotCzarny>
why do you care about sinovoip? they are just clone makers
<NiteHawk>
SinoVoip (useless, they never fix anything) <-- this :D
<tkaiser>
I care about their users. But that's also useless since even if they fix anything they don't provide the fixes to their users
<KotCzarny>
tkaiser, if you care about their users, then just try to promote armbian
<NiteHawk>
nevertheless, this should be documented as an issue for their sun8i github repos
<tkaiser>
NiteHawk: I just wait for KotCzarny. If he confirms the issue is resolved I open two issues and point them to the patch that fixes it (otherwise nothing will happen)
<jelle>
I'm shocked
<KotCzarny>
tkaiser: installing (though that opi runs on old/slow sd, so might take a while)
<tkaiser>
jelle: Really? Why?
<jelle>
tkaiser: because that's horrible
<KotCzarny>
also, can you provide cmdline? because apparently you use initrd
<KotCzarny>
unless its not needed and will work when booting straight to rootfs
<tkaiser>
KotCzarny: Should just work without modification.
<KotCzarny>
k, reboot time, i hope you have included module for my 8188eu ;)
<tkaiser>
jelle: I would suspect more of this stuff is present in these 'Android sources'...
<jelle>
hmmm
<jelle>
haven't run any AW android image yet
<jelle>
and for the two tablets I have, I want to have them on linux as soon as possible
tipo has quit [Remote host closed the connection]
<KotCzarny>
otoh im planning to have dual boot to droid too for one of my boxes
tipo has joined #linux-sunxi
<jelle>
KotCzarny: for which purpose?
<KotCzarny>
jelle: for fun
<KotCzarny>
and tv time
<jelle>
ohh
* jelle
is happy with openelec
<jelle>
although maybe later I want to use my orange pi pc for it
<KotCzarny>
tv time == playing games on tv
<jelle>
KotCzarny: ohh
<tkaiser>
jelle: I was referring to these BSP kernels we deal with (3.4 stuff for sun4i/7i/8i or 3.10 for sun50i)
<jelle>
tkaiser: yeah I get that ;-)
<jelle>
luckily haven't been required to touch them very often
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
<KotCzarny>
drat, forgot to update boot.scr
<jelle>
KotCzarny: I have my shield for games :p
<jelle>
nvidia shield
<KotCzarny>
brb
jernej has joined #linux-sunxi
<tkaiser>
KotCzarny: What about /proc/sunxi_debug/? :P
lemonzest has joined #linux-sunxi
<KotCzarny>
tkaiser: kernel didnt boot and my gf called, im connecting serial cable now
tkaiser has quit [Ping timeout: 276 seconds]
lamer14620272440 has joined #linux-sunxi
<KotCzarny>
tkaiser: kernel didnt boot and my gf called, im connecting serial cable now
<KotCzarny>
oh, woo, fel mode
<KotCzarny>
Wrong Image Format for bootm command
<KotCzarny>
drat. fixing.
<KotCzarny>
no more sunxi_debug
<lamer14620272440>
KotCzarny: Sorry for the invonvenience. I thought this would be a 'normal' Armbian image since then it's really just dpkg + wait + reboot
<lamer14620272440>
Ah great, thx!
<KotCzarny>
tkaiser: nah, its just me forgetting to fix the script
<KotCzarny>
that's what you get for doing things own way ;)
<lamer14620272440>
KotCzarny: Thx anyway. And now leaving for beergarden. Cheers! :)
<KotCzarny>
just to make sure, it was at /proc/sunxi_debug/ right?
<KotCzarny>
on a side note, did you guys at armbian broke /dev/ttyS0 console?
reinforce has quit [Ping timeout: 260 seconds]
<lamer14620272440>
KotCzarny: It was /proc/sunxi_debug/sunxi_debug and with this 3.4 variant we can only either use ttyS1 or ttyS0 but not both. So someone decided to prefer display instead of serial console.
<KotCzarny>
hrm
<KotCzarny>
i think i had display working via hdmi and serial console at the same time
<KotCzarny>
unless you talk about dsi
newuser has joined #linux-sunxi
<lamer14620272440>
KotCzarny: I just spoke about serial console while booting. You can define either or in boot.cmd but AFAIK not both (then you get nothing IIRC). Maybe it works maybe not, as soon as mainline kernel is ready I throw this 3.4.x stuff in the bin
newuser is now known as newpine64user
<KotCzarny>
btw. it worked for the most of the boot
<KotCzarny>
stopped just after display getty prompt
<lamer14620272440>
KotCzarny: Hmm... maybe new issue. But I can't test anyway. And am heading towards beergarden right now :)
scream has quit [Remote host closed the connection]
<KotCzarny>
so, what is 'gen_check_code' in legacy kernel?
<KotCzarny>
and can it be RE'd ?
<KotCzarny>
it says 'not stripped'
apritzel has quit [Ping timeout: 244 seconds]
<KotCzarny>
oh, wow, someone already did it
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<KotCzarny>
tkaiser: after patching i had to do some fixups, first was to add 'mksunxichecksum' from http://moinejf.free.fr/opi2/kernel-3.4.patch to get rid of that x86_64 binary requirement
<KotCzarny>
after patching i had to do some fixups, first was to add 'mksunxichecksum' from http://moinejf.free.fr/opi2/kernel-3.4.patch to get rid of that x86_64 binary requirement
<Dev184_>
I grabbed the rtl8723bs driver form hadess (https://github.com/hadess/rtl8723bs) compiled it and tried to load the issue is that I get a EBUSY from drivers/mmc/core/core.c __mmc_start_request
<NiteHawk>
Dev184: yes; 3.4 ("legacy") kernel uses .fex, not .dtb - and it's a good idea to try a different kernel to see if current 4.6.x maybe introduced some regression
<Dev184_>
Cheers, NiteHawk will do as soon as I get home from holiday
jernej has quit [Ping timeout: 244 seconds]
Dev184_ has left #linux-sunxi [#linux-sunxi]
<oneinsect_>
quick question if i change the debug port from console=ttyS0,115200 to a general console=ttyS1,115200 port...will it work?
<oneinsect_>
during u-boot and subsequent .....
<oneinsect_>
will it show anything?
<oneinsect_>
okie not working...kinda strange
<oneinsect_>
its not even booting if i change it to ttys1....that is weird ..
<KotCzarny>
dont know if they must be configured in .fex first as serial instead of gpio
<oneinsect_>
aha
<oneinsect_>
let me check it with bin2fex
<KotCzarny>
hurrah, i've found missing 'early printk'
<KotCzarny>
bugger was hiding in 'kernel low-level debugging functions'
p1u3sch1 has joined #linux-sunxi
<oneinsect_>
bin2fex says malformed data about script.bin ...wonder whats wrong
<KotCzarny>
sd corruption?
<KotCzarny>
maybe wrong version?
<oneinsect_>
ummm
<KotCzarny>
heh, enabling early printk booted the kernel
<KotCzarny>
o.O
<KotCzarny>
3.4.112+ /me happy panda
<NiteHawk>
huh? earlyprintk was meant to help you diagnose problems (i.e. where your previous kernel might have got stuck). maybe it's more the recompile that solved it?
<oneinsect_>
what is with 3.4.112+...any important updates?
VargaD has quit [Ping timeout: 276 seconds]
VargaD has joined #linux-sunxi
pekka10 has joined #linux-sunxi
willmore has quit [Remote host closed the connection]
<KotCzarny>
nitehawk: maybe, it booted and im happy.
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Equilibrium 4.2.0, revision: 42021, sources date: 20120701, built on: 2013-10-21 12:25:22 UTC 42021 http://www.kvirc.net/]