<Dreadlish>
you have to build it, not copy source.
<shineworld>
ok, but I need to compile Android TV with old kernel (which create the zImage that I've to ignore), build separately linux-sunxi kernel (with same configurations used by android tv version) get the resulting uImage and make the zImage to put in Android TV output ?
<Dreadlish>
probably.
<shineworld>
uhm... I will try ...
calris has quit [Ping timeout: 256 seconds]
calris has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
horon is now known as zumbi
ynezz has left #linux-sunxi [#linux-sunxi]
wingrime has joined #linux-sunxi
<wingrime>
mnemoc: you can push ramconsole patch )))
<wingrime>
ssvb: are you pushed NEON patch ?
<ssvb>
wingrime: the code is partially available in 'neonblt' branch (but still not really enabled there)
<ssvb>
wingrime: as soon as I'm absolutely sure that there are no regressions in any of possible configuration, it will be pushed to master
Guest41045 is now known as fredy
torqu3e has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
ganbold_ has joined #linux-sunxi
<mnemoc>
wingrime: pushing 45 patches, including that one, now
<wingrime>
mnemoc: great, you finlay come back))
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
rz2k has joined #linux-sunxi
<mnemoc>
wingrime: still not fully back, but trying
<mnemoc>
going to push rebased stage/* now
<mnemoc>
stage/sunxi-3.4 still test building...
<wingrime>
mnemoc: why you still consider 3.4 as unstable?
<wingrime>
what "mailstone" or "blocking problems" with it?
rellla has quit [Remote host closed the connection]
<mnemoc>
i don't consider it unstable. only waiting for feedback from android people to "deprecate" 3.0
<mnemoc>
and then focus in 3.4 and sun[67]i forward porting (from allwinner's 3.3)
<wingrime>
I wait it too, I don't wand download cm and build it (many many times for it)
<mnemoc>
also would like to sort out the defconfig mess before deprecating 3.0
<mnemoc>
to avoid having unnecesary forks
<wingrime>
mnemoc: a13 config must have some stuff to add
<wingrime>
mnemoc: cpufreq, pm ,otg
<wingrime>
mnemoc: some cpu gonverors are broken for module build
<mnemoc>
imo we don't need spartan "defconfigs" like mainline, we need configs that can be used. per soc and per target (desktop, android, headless)
dolence has joined #linux-sunxi
<mnemoc>
the variants because removing all the mali/cedarx stuff is not trivial, and enabling anroid is also not trivial
<dolence>
hey guys! I'm trying to limit my resolution to 720p but my system always boot to 1080p, isn't that on script.bin?
<mnemoc>
i test all defconfigs after merging patches, stuff that isn't enabled there it's missed
<dolence>
screen0_output_type = 3
<dolence>
screen0_output_mode = 5
<mnemoc>
dolence: it might be that edid is taking precendence
<mnemoc>
you can override that via /proc/cmdline
<dolence>
hmmm
<dolence>
makes sence
<dolence>
*sense
<dolence>
sorry
<mnemoc>
new stage/sunxi-3.4 pushed
<mnemoc>
cec still there, and some others, waiting for more feedback
<mnemoc>
sunxi-3.0 or sunxi-3.4 it mostly the same
<mnemoc>
the stage branches are for testing things
<dolence>
I'm using 3.4 but not the stage one
<mnemoc>
mostly for devs
<mnemoc>
dolence: I just updated sunxi-3.4, it includes some disp stuff
<dolence>
I will test it
<dolence>
since /proc/cmdline says 1280x12024 it should be restrict to that, right?
<mnemoc>
`dmesg` might tell why it's not sueding that
<mnemoc>
but try the latest sunxi-3.4 first
<mnemoc>
.oO(where is techn?)o
<wingrime>
mnemoc: how about importing warning minimization feature from msm
<wingrime>
?
<wingrime>
yesterday I talking about it
<mnemoc>
ML
<mnemoc>
not my call
<mnemoc>
propose it there and see what other devs think about it
<wingrime>
all devs already there, we have not so much people
<mnemoc>
the ML has an async nature irc doesn't
<mripard_>
and retrieving archives of an IRC conversation is a pita.
<mnemoc>
ML is better :)
<mnemoc>
for those things
<dolence>
what's ML?
<mripard_>
mailing list
<wingrime>
mnemoc: I still want gitweb and maillist infrastructure
<wingrime>
and I think thereis some organizations that will host it for free
<dolence>
I see
<wingrime>
simply github too annonyng slow for me
<wingrime>
also night builds are awesome , and bugzilla
<mnemoc>
wingrime: I asked almost every hosting of arm/linux related things about hosting a ML for us. those who cared to answer considered our goal unworthy
<dolence>
gitweb is a local version of github?
<dolence>
I mean, you can run your own github...
ibrah has joined #linux-sunxi
<mnemoc>
not github, just a normal web view of git repos
<dolence>
I never did it before... anyone can write?
<ssvb>
mnemoc: this EDID related knowledge seems to be already there :)
<ssvb>
dolence: where did you get your current kernel cmdline?
<dolence>
You can specify a fixed mode like disp.screen0_output_mode=1280x1024p60 or a fallback in case EDID did not work disp.screen0_output_mode=EDID:1280x1024p60.
<dolence>
it was already there
<ssvb>
ok, so you used the right wiki page, but just misinterpreted the information a bit
<dolence>
ssvb, I did a debian LFS using wiki as guide
<dolence>
ssvb, yes...
<mnemoc>
ssvb: true :)
<dolence>
I dont know how to say it in english, but I think it was more like a lack of attention
<mnemoc>
improve that paragraph to be easier for other users with attention problem ;-)
<mnemoc>
that's why it's a wiki
<dolence>
I will
<ssvb>
mnemoc: +1
<oliv3r>
i guess i can give feedback on android once I can get mine to boot a custom kernel :( tom did say he'd send me a cubieboard and SD adapter :D
<ssvb>
wingrime: are you using cedarx?
<dolence>
can It be the inverse? a fixed output mode and edid as fallback?
<dolence>
something like disp.screen0_output_mode=1280x1024p:EDID
<oliv3r>
mnemoc: i can setup a mailman service if that's what's required. i don't think linux-sunxi is any bothersome traffic
<wingrime>
ssvb: tryed but no way on debian
<wingrime>
ssvb:may be a should updare last vlc
<wingrime>
ssvb:look like it have fix
<oliv3r>
wingrime: and I'll export our git to my personal cgit that you can pull from ;)
<mnemoc>
but no idea what side effects that might have, because I don't know why they use it. root= maybe?
n01 has joined #linux-sunxi
hramrach has quit [Ping timeout: 276 seconds]
hramrach has joined #linux-sunxi
<shineworld>
ok I don't use android ramdisk system so I'm fine
<oliv3r>
wingrime: so you actually care about opensource. well luckly in here most if not all do :) the world though; a different place
<oliv3r>
mnemoc: refresh my memory, mandatory for?
<wingrime>
oliv3r: I simply want my hardware work quck and have fresh soft , not simple drop all support as factures do
<oliv3r>
wingrime: :)
<oliv3r>
for me, the OSS part is important
<oliv3r>
i'm appalled that we have to do the work the manufacturer refuses to do (or doesn't do properly)
<wingrime>
oliv3r: thats market
<wingrime>
when you bye something thay work enfs
<wingrime>
*ends
<wingrime>
apple understand one thing that have not be undestanded for years - ecosystem
ganbold__ has joined #linux-sunxi
<wingrime>
thay build store and win
<wingrime>
any device can give vendor money after bying
<oliv3r>
yep, and while i think their products look awesome
<oliv3r>
apple is evil
<wingrime>
after steve died thay begin make errors that should not
<wingrime>
unforunaly thay begin think about money
paulk-desktop has joined #linux-sunxi
<wingrime>
broke device lifecicle
<wingrime>
make smal ipad
ganbold_ has quit [Ping timeout: 260 seconds]
<wingrime>
all consumers know, thay apple device is cool in around a year, than it becomes piece of shit for 3rd world
<wingrime>
and thay keep prices hier than others (on small fee) for make thay feel that it premium device and you cooler than that guy with LG,samsung etc
<mnemoc>
oliv3r: boot.scr been mandatory to run android. it's forced by our bsp (optional for linux), and not sure if something breaks by making it optional
user has joined #linux-sunxi
<user>
Hi, does the sunxi kernel support squashfs?
<dolence>
my english is crappy, so if are anything wrong, please just let me know
<mnemoc>
user: not yet. but the mtd driver is in progress
<mnemoc>
dolence: looks good :)
<dolence>
ty
<mnemoc>
i suppose we can add a (commented out) sample boot.cmd file in the bsp
<mnemoc>
to tell people how to do things, and avoid shineworld's problem
<bfree>
mnemoc: how do squashfs and mtd connect? squashfs works fine as long as your kernel config builds it (I suspect it's not in the defconfig though)
eebrah has joined #linux-sunxi
<mnemoc>
bfree: I had the (wrong) idea squashfs needed an mtd block
<n01>
uhm ... you can use squashfs also with mtdblock
<bfree>
nah, it's commonly used for e.g. live systems (e.g. in iso's)
<user>
ok
<user>
yeah, live systems
<wingrime>
I try do some profiling
vinifm has quit [Ping timeout: 258 seconds]
rz2k has quit []
<dolence>
what we need to have xbmc video accel working like in M3 devices?
<dolence>
I mean, it's a XBMC thing or mali drivers side?
<mnemoc>
mali is 3D, cedarx is video decoding
<dolence>
ah, and cedarx is fully implemented?
<mnemoc>
cedarx is a blob, rellla's xmbc has bindings for it
<mnemoc>
don't know the state for other players/frameworks
<mnemoc>
still hoping wake up one day and see someone announcing an libva plugin for cedarx...
<paulk-desktop>
mhh, it seems that I need to push the keys much harder to have an input event created with the sunxi-3.0 kernel than with the stock one
<paulk-desktop>
any explanation?
<dolence>
mnemoc, and what about libstagefright?
vinifm has joined #linux-sunxi
<wingrime>
hramrach: are you here
<wingrime>
?
dolence has quit [Read error: Connection reset by peer]
<hramrach>
wingrime: yes
<wingrime>
are you touched aw_clksrc_read
<wingrime>
?
<wingrime>
I tryed make profiling with perf
<hramrach>
not likely
<wingrime>
and noticed that aw_clkscr_read have 5%
<wingrime>
sometimes
<wingrime>
it strange
<mnemoc>
ouch
<wingrime>
but it maybe side effect
<wingrime>
of profiling
<hramrach>
it does busy wait
<hramrach>
while(TMR_REG_CNT64_CTL & (1<<1));
<hramrach>
does raw_local_irq_save and restore have siginificant time too?
<wingrime>
it realy interesing
<wingrime>
as manual says we have latch output register
<hramrach>
if not then waiting for the read is probably responsible
bsdfox has quit [Ping timeout: 260 seconds]
<wingrime>
good question
<wingrime>
see a13 manual
<wingrime>
it unclear
<wingrime>
page 102
<wingrime>
I don't realy understand have we wait or not
dolence has joined #linux-sunxi
<hramrach>
there is wait so it's there probably for a reason
<hramrach>
maybe look for different versions of that code
<wingrime>
please)
<wingrime>
i contine search bad places with perf
<hramrach>
I did not really try profiling on A10
<hramrach>
the profiler takes too much time
<hramrach>
quantum uncertainty effect in large scales ;-)
<wingrime>
it realy intersting that __dosoftirq so freq
hramrach has quit [Remote host closed the connection]
<wingrime>
perf log complitly different with x86
hramrach has joined #linux-sunxi
<hramrach>
it's very terse description
<hramrach>
but likely the wait is required
<wingrime>
busy-wait in hi-performane
<hramrach>
you need not busy wait, technically
<hramrach>
but busy wair is easieast implementation
<hramrach>
and htere is no interrupt so you need to poll
<hramrach>
and no spec of exected delay :s
<wingrime>
hramrach: it look like hardware problem
<wingrime>
hramrach: or simular
<wingrime>
hramrach: this is hi-freq timer
<wingrime>
hramrach: we need getvalues at some moment
<hramrach>
or you use the hardware in different way than designed for or th driver is just lousy because normally it is seldom used and does not show as perf bottleneck
<wingrime>
hramrach: but unmbers can change
<mnemoc>
they have a real time os. I doubt the hardware doesn't support anything better
<mnemoc>
just a lazy "get android running now!"
<wingrime>
mnemoc: this is not realy fearing thing
eebrah has joined #linux-sunxi
<wingrime>
mnemoc: fearing thing is a branch-misses
<wingrime>
pref talk to me that 9% misses
<mnemoc>
review the lichee/*-dev branches :)
<wingrime>
on syntetic test
<mnemoc>
ah, sorry. wrong usage of "branches"
<oliv3r>
mnemoc: I don't know if it's mandatory;from what I understand it is a uboot script. and boot0/1 don't use uboot
<oliv3r>
mkbootimg doens't have an argument to use boot.scr
<wingrime>
hramrach: more interesting, have we cache-miss on branch-miss ?
<hramrach>
presumably kernel tasklets use softirqs
<hramrach>
that depends on arm impl and cpu settings
<hramrach>
you can technically preload both branches but takes up more space
<hramrach>
also arm has those post-branch instructions that are executed regardless of branch result so more likely we have useless nops rather than cache misses
<wingrime>
hramrach: great question for me, why a10 looks waker than ipad 1 but have simular specs
<ssvb>
wingrime: we might want to check if this bit is set and clear it if necessary
<hramrach>
wingrime: probably needs better graphics dirvers and better tuning
<hramrach>
OS X used to work flawlessly with 100% software rendering
<wingrime>
hramrach: I fear that also relaed hw design
<wingrime>
hi-performance system have many bottle-neeks
<hramrach>
there is ample room for optimization wrt interactive response
<hramrach>
it's largely neglected on Linux becasue it's 'fast enough' on beefy desktop systems
<hramrach>
as long as they perform at least as an i386 ..
<ssvb>
wingrime: cortex-a8 in ipad 1 has larger L2 cache (512K vs. 256K) and also possibly faster memory, apple really does care about memory bandwidth in their products
<wingrime>
ssvb: enable neon opimization for nenobit branch
<wingrime>
ssvb: I wan;t test
<ssvb>
wingrime: working on that, be patient :)
<hramrach>
hope allwinner takes the lesson and makes the dram controller faster on A20
<hramrach>
but probably too late for a20 already :s
<oliv3r>
a20 is allready in production isn't it? i know they needed a week or two more to fix some things
<oliv3r>
though hipboi said it was delayed again, so amybe they fix stuff :)
<oliv3r>
I personally wouldn't be supprised if they're allready mostly working on A40 (or whateer sun8i is
<hramrach>
quite possible
<hramrach>
like testing team doing a20 designers doing the next
<oliv3r>
i think hipboi did mention it'll be a big-little design
<ssvb>
wingrime: right now my a10 device is busy running testu01 test for prng right now (Turl might be interested), seems like it is going to take a bit more time than expected
<oliv3r>
so 2:2 and 4:4 probably
<oliv3r>
or 1:4 even
<Turl>
ssvb: :)
<hramrach>
ASMP ..
<oliv3r>
asmp?
<hramrach>
not SMP
<mnemoc>
big.LITTLE thing
<mnemoc>
not all cores are equal
<hramrach>
asymmeric
<mnemoc>
until the little guy is incompatible with the big guy.... like A31's ar100 :(
<hramrach>
JIT
<wingrime>
ASMP as i remeber when OS run on one core, application to anouser
<hramrach>
maybe android can run on the ar100 as well?
<wingrime>
hramrach: ar100 look like will do baseband late
<wingrime>
on a40 for example
<ssvb>
hramrach: I guess it depends on whether the openrisc core has been configured with MMU support or not
<hramrach>
would be cool hack to make it run there
<mnemoc>
a31s is the phone thing, also sun6i
<hramrach>
yeah it might be really stripped down
<wingrime>
hramrach: it can ulinux without mmu
<mnemoc>
if a40 happens, I bet it will be sun7i
<hramrach>
I don't think android runs on ulinux
<wingrime>
hramrach: you can emualte arm on ar100 and run linux and android
<wingrime>
software emulation
<ssvb>
TI chips have some simple cortex-m cores in their OMAP
<ssvb>
it could be that the openrisc based ar100 core is intended to be used for similar purposes
<calris>
OK, so linux-sunxi/u-boot-sunxi will be mainlined eventually
<mnemoc>
calris: yes
<calris>
Great
<calris>
Thanks
<calris>
That's what I cloned already
<mnemoc>
calris: sunxi-current aims at mainlining. sunxi is just "stable"; lichee-dev is purely based on allwinner's + ATAG fixes to let us remove allwinner boothacks
<shineworld>
well working also GFX (watched capturing screen with DDMS)
<oliv3r>
mnemoc: then you should test your cubieboard at 520 Mhz; hiboi said it works :)
<shineworld>
I will install a vncserver so I don't need of a monitor
<mnemoc>
shineworld: can you review the differences between our cubieboard{,_512}.fex and the one included in new devices?
dolence has quit [Quit: Saindo]
<shineworld>
ok ... I've the cubieboard.fex (bin) obtained with BSP ./configure cubieboard-android and that on nanda of a new device
<shineworld>
time to meld them
<mnemoc>
but please don't do it blindly. only relevant parts
<mnemoc>
they probably just took the template from a newer SDK and adapted it agin
<mnemoc>
again*
<mnemoc>
the point of sunxi-boards is to have verified .fex files we can rely on
<mnemoc>
and then use those to generate the .dts files
<mnemoc>
and u-boot dram info
<hramrach>
wingrime away again :s
<hramrach>
anyone can test sun5i suspend?
<oliv3r>
ssvb: did you take turl's pasted code and ran the test on that?
<shineworld>
nope just the two files... to compare I'm using meld (overall I'm a windows's guys very new to linux things)
<mnemoc>
shineworld: unfortunatelly I can't :(
<shineworld>
how to use diff ?
<oliv3r>
mnemoc: btw, i'm not very convinced with the quality of the sdk FEx templates. I was going over TV out code from disp from various branches, and unless I overlooked a branch, all fex tepmlates blindly state 'dac0_src = [0-8]' for composite, Luma, Chroma etc'
<ssvb>
oliv3r: yes, I took Turl's pasted PRNG code and ran it through http://en.wikipedia.org/wiki/TestU01 (with just 'volatile' keyword added for memory accesses)
<oliv3r>
mnemoc: nowhere, not anywhere is that variable used in the fex. they only parse 'dac_used = 1' and that's it. the code does have some fixed set choices. I only did some little research on the disp dir's, other then them being a huge mess, is it fair to say, you load a certain display driver if you want a certain output (tv, hdmi, vga)? i haven't used disp really or does that come from the disp setup?
<oliv3r>
ssvb: ah ok so no kernel driver yet
<mnemoc>
oliv3r: tried the -dev branches?
<oliv3r>
ssvb: i started working on that :)
<oliv3r>
mnemoc: yeah, was mostly looking at sun7i
<oliv3r>
so it's probably the y'wanted' to offer that :p
<mnemoc>
:)
<oliv3r>
also, find it interesting how they use the 4 dacs though
<oliv3r>
from what I understand, their plan|how they do it, is that you can setup the 4 dac's in any combination or configuration you want, either just composite, or svideo, or YUV, or RGB (for use with scart I assume to; and for VGA)
<oliv3r>
you probably can use any combination too, so 4x composite, while initially useless, should be possible
<oliv3r>
if you wanna say clone it to 4 tv's
<oliv3r>
it's quite flexlibe, IF it actually works like that in hardware, and not just 'almost in code'
<oliv3r>
but it would require the entire disp layer to be rewritten and 'fixed'
<oliv3r>
ssvb: it may take a few weeks, but i hope to have an initial module for prng
<oliv3r>
and i tlak to much again :)
<oliv3r>
shineworld: the new cubieboard actualy set the machine='cubieboard' it is the first one to officially actually do that :)
<oliv3r>
oh, pll4 and 6 are now 'mcuh higer clocked
<shineworld>
yes 1200 instead of 960
<ssvb>
oliv3r: sounds good, anyway it's up to you and Turl to decide who is doing what ;)
<oliv3r>
ssvb: yeah i'll poke turl what he wants to do
<shineworld>
ok time to reboot
<oliv3r>
shineworld: dram_para is not accurate from script.bin
<shineworld>
I'm only watching what is in virgin cubieboard card vs what generated from sunxi-bsp
<oliv3r>
shineworld: livesuit 'injects' the dram_para's into boot0 during flash, so we 'technically' can't know it, but when you boot from nanda, you use boot0 and thus ram is initialized to whatever was set by the livesuit injection
<mnemoc>
shineworld: can you run a10-meminfo-static on that stock os on nand of that virgin cubieboard?
<oliv3r>
shineworld: no worries; you found out something valueable; that's always good.
<oliv3r>
shineworld: from my slow non-focus memory, the higher clkdiv, means a lower core clock for the mali. this may be due to a higher clocked pll6 (pll4 was the video encoder i belive)
<shineworld>
I've to learn more possible from this irc because, after, I've to teach same things to my collaborators which have to use same board
<oliv3r>
shineworld: lol there is much to learn, we try to keep all info on the linux-sunxi.org wiki :)
<shineworld>
of course, I'm always on these pages :)
<oliv3r>
shineworld: i think pll4 may be used for mali on cubieboard, so that's rpobably why they increased the div :)
<shineworld>
but you know industry... few time to learn, run run run
<oliv3r>
shineworld: haha, A10 is pure hobby fo rme; if anybody wnats to offer me a job ... :p
<oliv3r>
shineworld: what are your plans for A10?
<shineworld>
HMI terminals for industry running at first android apps
<oliv3r>
shineworld: lcd_bl_en_used is a 'correction' there's no LCD backlight ;p
<oliv3r>
shineworld: where your from
<shineworld>
Italy, north-east
n01 has quit [Ping timeout: 240 seconds]
<oliv3r>
the lcdclk, lcdde etc para's are probably just corrections, there's only one way to wire those pins
<shineworld>
actually we are using a proprietary RTOS with a simple GUI but I would like to move in more powerful environment
<shineworld>
I'm trying to connect LVDS displays
<oliv3r>
cubieboard should allow that iirc
<shineworld>
I've got some problems with power-supply yesterday
<oliv3r>
shineworld: i saw there's a cubie baseboard (sold out) that has LVDS 'breakout'
<oliv3r>
shineworld: csi_used disabled makes sense, there's no camera on the cubieboard :)
<shineworld>
I've tried to buy but is "SOLD OUT"
<oliv3r>
same goes for mmc1
<shineworld>
are you a tabled A1x user ?
<shineworld>
*tablet
<mnemoc>
an almost bare pcb with 0.1" for 3/4th of the price of the cubieboard.... uhm
<oliv3r>
the breakoutboard is HUGELY overpriced
<shineworld>
and backlight power supply
<shineworld>
yes
<oliv3r>
but it is very neat for what it offers and does
<oliv3r>
if your a company, it's still nothing in your budget :)
<oliv3r>
the 'combo' is outrageously priced; 90 USD
<oliv3r>
shineworld: yes, only tablet A10 here , but cubieboard on the way
<shineworld>
at this moment I've in mind only the "required time to have a prototype"
<shineworld>
I've 4 cubies on desk
<oliv3r>
shineworld: :D
<shineworld>
2 board iMX6 powered
<shineworld>
2 and 4 cores
<oliv3r>
shineworld: anyway, it looks like the new 'fex' fixes a lot of 'mistakes' for some PIO's
<shineworld>
new 'fex' your mean that in the nanda ?
<oliv3r>
shineworld: does any of your cubie boards have a g-sensor?
<oliv3r>
shineworld: yeah
<shineworld>
I don't think have a g-sensor
<oliv3r>
shineworld: they claim to have a 'gsenser' now instead of the 'very often used' bma250. also before it was 'disabled' and now its 'enabled' so that clearly must be a bug
<shineworld>
ok so I will use the nana/script.bin for my build
<shineworld>
a sec I watch the logcat messages
<oliv3r>
shineworld: you can always make your own :p
<shineworld>
I've already modified to support LVDS
<shineworld>
but I'm not sure of changes so monday morning I will try with hardware
<oliv3r>
shineworld: they setup usbc0 as a 'device only' port (not OTG what we normally see) but that's fine, since it has 2 host ports and OTG is being troublesome enough
<oliv3r>
they also enabled 'usb wifi' by default, which I don't get
<oliv3r>
because that's only for the soldered wifi, so that should be disabled
<shineworld>
D/Sensors ( 152): open_sensors0!
<shineworld>
D/Sensors ( 152): g sensor get class path error
<shineworld>
E/SensorService( 152): couldn't open device for module sensors (Operation not p
<shineworld>
where you come from oliv3r ?
<oliv3r>
shineworld: NL :)
<oliv3r>
shineworld: looks like there's no G-sensor :p
<shineworld>
yeah
<oliv3r>
so their new fex is 'broken' as usual :p
<shineworld>
seem just a copy/paste from another board
<oliv3r>
once i have my cubie, i'll spend osme time fixing the stock fex
<shineworld>
;)
<shineworld>
have you ordered one ?
<oliv3r>
shineworld: one is on its way I think
* mnemoc
has two, nicely stacked.... on a to-be-determined box :(
<oliv3r>
mnemoc: is the 'move' done? is all your stuff in the new house?
<shineworld>
stacked ?
<oliv3r>
or do you have to paint everything still?
Dave77 has quit []
<oliv3r>
shineworld: be carefull with [dynamic] MAC = "00000"
<oliv3r>
check wired MAC and write it down somewhere :)
<oliv3r>
but you'd think hardware accelerated it should be faster
<ssvb>
I guess the hardware PRNG is not very useful without DMA
n01 has joined #linux-sunxi
<ssvb>
just reading the hardware registers using the CPU for one random value at a time is not going to be really fast
vinifm has quit [Quit: Ex-Chat]
<oliv3r>
i'll sound really stupid now, and say i didn't know you had to use dma for that :)
<ssvb>
well, even more stupid would be to use one ioctl per one random number, this is going to be really slow
<ssvb>
the only way it can be fast is to generate a sufficiently large buffer of random numbers and then fetch numbers from this buffer until they are used up
<ssvb>
and when they are all used up, just generate another batch
<ssvb>
the hardware accelerated PRNG driver can be probably somehow hooked as a backend for /dev/random and /dev/urandom
<ssvb>
except that we don't really know what kid of algorithm is used for it and whether it can be really trusted
<oliv3r>
ssvb: i've never done DMA programming. I know it's 'direct memory access' but thats where it stops for me :(
<oliv3r>
ssvb: i just assumed you connect it somehow to /dev/random and it would magically spew out random numbers as requested. that speed would be an issue and overhead, I didn't know. well if turl'll let me, that'll be a good programming excersize :)
<oliv3r>
and prng should be trivial enough that it's actually possible :)
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
<oliv3r>
ssvb: i once read a little but about the kernel's /random and /urandom and 'true randomness' (i think it's from that lwn article)
<oliv3r>
-but
<oliv3r>
(and i have to re-read that article) but i think the hardware crypto engine's don't actually supply random data, they feed the kernel's random generator to get 'better' randomnes
<oliv3r>
though we shoulnd't call it PRNG if it really turns out to be a HWRNG :)
<oliv3r>
Turl: ^
<oliv3r>
oh, in 3.6 there was something called Arch HWRNG introduced, i thik that's what I ment with 'feed the kenrel' That IS the article I read las december
drachensun has joined #linux-sunxi
<oliv3r>
to summarize, the kernel has a CSPRNG (implemented in software) that should be really good. If you have a hwrng that gets XORed with it. The reason why they don't use the HWRNG by itself, if it turns out to be a crap algorithm or not fully reliable, it doens't really have to be an issue due to the xor-ing