ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
ganbold has joined #linux-sunxi
torqu3e has quit [Quit: torqu3e]
bsdfox has quit [Ping timeout: 264 seconds]
egbert has quit [Ping timeout: 246 seconds]
egbert has joined #linux-sunxi
<WarheadsSE> well, pcDuino support to uboot was stupid easy, as usual.
bsdfox has joined #linux-sunxi
<WarheadsSE> and patch sent.
ibrah has joined #linux-sunxi
ibrah has quit [Ping timeout: 255 seconds]
RaYmAn has quit [Ping timeout: 256 seconds]
RaYmAn has joined #linux-sunxi
bsdfox has quit [Ping timeout: 260 seconds]
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
eebrah has joined #linux-sunxi
fredy has quit [Ping timeout: 245 seconds]
Guest41045 has joined #linux-sunxi
bsdfox has quit [Ping timeout: 260 seconds]
n01 has joined #linux-sunxi
hramrach has joined #linux-sunxi
ibrah has joined #linux-sunxi
rellla has joined #linux-sunxi
ibrah has quit [Ping timeout: 260 seconds]
shineworld has joined #linux-sunxi
<shineworld> A question for GURU : to update to more recent kernel the Android TV ( is only necessary to fill /kernel/allwinner/common/ path with contents of repository (branch sunxi-3.0) ? ?
eebrah has quit [Ping timeout: 258 seconds]
<Dreadlish> nope
<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
<dolence> my cmdline says
<dolence> console=tty0 disp.screen0_output_mode=EDID:1280x1024p60 root=
<dolence> should I be using stage or stable one?
<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
<mnemoc> lxr is also on the TODO
<mripard_> wingrime: you know, in open source, when you really want something, usually, you do it yourself
<mripard_> this is how it works
<n01> oh god, LXR please :)
<wingrime> mripard_: I know, i do it
<n01> does a sort of lxr hosting exist?
<n01> like a github for lxr?
<mnemoc> hope to have time to add those things in the linux-sunxi server around mid april
<mnemoc> mailman, git mirror, gitweb and lxr.... beside moving the wiki from the old server to the new
<dolence> cant we ask for donations?
<mnemoc> donate time, that's the most we need
<wingrime> mnemoc: I saw this (you can translate )
<wingrime> mnemoc: free hosting for some projects )))
<mnemoc> it's not a matter of free or not free. it's about having time to set up things
<mnemoc> fortunatelly I have no troubles with the money part currently
<mnemoc> lima otoh, as it's luc's full time project, probably would appreciate donations a lot more
<wingrime> mnemoc: glat see that
<wingrime> *glad
<ssvb> dolence: just try to replace "disp.screen0_output_mode=EDID:1280x1024p60" with "disp.screen0_output_mode=1280x1024p60" (remove "EDID:" part)
<wingrime> mripard: what with nand docs?
<ssvb> dolence: because your current config means to use EDID and fallback to 1280x1024p60 only if EDID fails
<dolence> ssvb, ok! I will try and report back
ibrah has quit [Ping timeout: 255 seconds]
<mripard_> wingrime: I didn't ask yet
<ssvb> dolence: btw, are you sure about 1280x1024? maybe it should be 1280x720 (if you have a widescreen monitor)?
<mnemoc> dolence: donate that new knowledge on the wiki :)
n01 has quit [Quit: leaving]
<dolence> omg, I feel so dumb now
<mnemoc> desperately wants that knowledge
<dolence> it really should be 1280x720 o_O
<dolence> mnemoc, I will test and update wiki
<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 ;)
<ssvb> wingrime: ok, just based on I thought that you got it up and running correctly
ganbold_ has quit [Remote host closed the connection]
<wingrime> ssvb: based on diffences between sun4i and sun5i
<wingrime> ssvb: it must be workable
ganbold_ has joined #linux-sunxi
<wingrime> oliv3r: we disscused about it
<oliv3r> i was to fast to respond, to slow to read :p
<oliv3r> time to run some tests of hansg's patches
vinifm has joined #linux-sunxi
<wingrime> ssvb: I need andoird to test it fully
<wingrime> ssvb: If you enable NEON in neonbit branch I will test it soon as possible
<oliv3r> wingrime: just out of curiosity, why are you so invested in sunxi? personal or work related? :)
rz2k has left #linux-sunxi [#linux-sunxi]
rz2k has joined #linux-sunxi
<oliv3r> either way, its really good to have you here
<wingrime> oliv3r: I just contine my personal intension
<wingrime> oliv3r: I too long try improve devices I have
<oliv3r> wingrime: awesome :)
<oliv3r> so so much work left to do though
<wingrime> oliv3r: I think modern mobile devices go to wrong way
<wingrime> oliv3r: only as content consume devices
<shineworld> I'm trying to build kernel for cubieboard-android with sunxi-bsp using:
<shineworld> ./configure cubieboard-android
<shineworld> make
<shineworld> make[1]: Leaving directory `/home/shine/android/build/linux-sunxi/sunxi-bsp/linux-sunxi'
<shineworld> But after a while I've got the following error:
<shineworld> cd /home/shine/android/build/linux-sunxi/sunxi-bsp/build/sun4i_crane_defconfig-linux && arm-linux-gnueabihf-objcopy -R -S -O binary vmlinux bImage
<shineworld> scripts/ /home/shine/android/build/linux-sunxi/sunxi-bsp/output/cubieboard_hwpack.tar.xz
<shineworld> Android hwpack
<shineworld> cp: cannot stat `build/boot.scr': No such file or directory
<shineworld> make: *** [/home/shine/android/build/linux-sunxi/sunxi-bsp/output/cubieboard_hwpack.tar.xz] Error 1
<shineworld> I've just now git clone the sunxi-bsp so should be aligned to last code
<shineworld> someone in last days re-inserted old way
<mnemoc> shineworld: you need to create a `boot.cmd` yourself... not sure what android expects there
<mnemoc> oliv3r: is it really mandatory or we can do it optional as for linux?
<shineworld> actually I don't need that because I want only resulting uImage (I'm booting with u-BOot -> uImage from uSD)
<mnemoc> echo '#' > boot.cmd ?
<mnemoc> boot.scr won't be created if the file is empty
<mnemoc> will make it optional
<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> hdmi section
<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 ;-)
eebrah has quit [Ping timeout: 256 seconds]
<hramrach> well,
<hramrach> I don't have manual
<wingrime> manual on
<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> mnemoc:hramrach:"
<wingrime> this is fearing
<oliv3r> so i just copy the kernel +modules from the build dirctory, but it doesn't boot, so maybe it is mandatory :)
<oliv3r> mnemoc: those comments on the ML; are just feedback. I will send my patchset for what needs to be done when done testing
<hramrach> weird
<hramrach> you get 300k branches out of 1.1M instructions and 0.02% missies
<hramrach> and 180k branches out of 2.3M instructions with 9% misses
<wingrime> hramrach: it means that intel CPU have perfect branch-prediction unit
<hramrach> but you also execute way less branches per instruction
<wingrime> hramrach: pref log for a13
<hramrach> so easier for the prediction
<wingrime> hramrach: __do_softirq
<wingrime> hramrach: for what we use soft-irqs
<hramrach> I have no idea, sorry
<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: older revisions of cortex-a8 had to invalidate branch prediction information on task switches (IBE bit in AUXCTRL - )
<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: possible more one botle-neck
<ssvb> wingrime: btw, can you try to run on your a13 system?
<hramrach> well, you should be able to get decent performance on a tablet display
<hramrach> it does not have that stunning resolution
<wingrime> 800x480
<ssvb> wingrime: for comparison, here are some results for other hardware (inclusing allwinner-a10) -
<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
<wingrime> ssvb: audio routing, firmware loading . baseband
<wingrime> sleep alarm,
<ssvb> yep
<wingrime> wakeup
<oliv3r> hi
<oliv3r> its late :p
<ssvb> but it's interesting that allwinner apparently did not want to license arm cortex-m and decided to use free opensource hardware instead :)
<oliv3r> personally, i'd love to see a 1:4 A40 based on sun7i
<wingrime> ssvb:
<oliv3r> ah asmp; yeah, that means everything runs either on the 1 core, or on the quads, but not on all 5
<ssvb> wingrime: thanks, looks like a13 is indeed quite a bit slower than a10
<ssvb> wingrime: have you interrupted the test because it was taking too much time?
<oliv3r> i'm supprised there's differences performance wise between A13 and A10
<wingrime> ssvb: it still runs
<wingrime> I use wifi and ssh
<oliv3r> well if ar100 is basedon opensouce hardware, atleast it should be easy to hack :p
<wingrime> xorg runs
<wingrime> oliv3r: nope, baseband will also have registers
<wingrime> you don;t realy know what thay do
<wingrime> ssvb: test still runs
<ssvb> oliv3r: a13 uses a slower memory controller (single channel 16-bit)
<ssvb> wingrime: thanks, do you happen to know SDRAM clock speed in this device?
<wingrime> I use a13_mid
<wingrime> not realy try to know on this devce
<wingrime> ssvb: can it run faster ?
<oliv3r> ooh wow, they really skimped on a lot of parts. I still think it's 'binnend' dies, broken bits etc
<oliv3r> it may be able to run at 480 MHz
<oliv3r> but remember, memory speed depends on quality of tracelayout
<oliv3r> appearantly cubieboard can run up to 520 MHz stably
<ssvb> A13 SoC itself supports up to 533MHz according to the datasheet
<oliv3r> and the A10? i thought i saw 600MHz somewhere
<ssvb> IIRC the datasheet says 400MHz for A10 :)
<oliv3r> 600*
<ssvb> oliv3r: "up to 800Mbps", which means 400MHz
<mnemoc> the max i've seen is 480
<ssvb> mnemoc: maybe they wanted to specify some standard memory clock speed in the datasheet (can work as DDR3-800, but can't do DDR3-1066)
wingrime has quit [Ping timeout: 260 seconds]
<shineworld> booted !!! boot.scr is not mandatory if I define uEnv.txt
<shineworld> unfortunately I don't have here a HDMI monitor to view display but at console seem to work
<calris> Can anyone tell me what the difference between amery's and hno's u-boot repos is? Is the amery repo the one used for Fedora 18
<mnemoc> shineworld: what's the minimal uEnv.txt ?
<mnemoc> calris: amery doesn't do u-boot
<shineworld> boot_mmc=fatload mmc 0 0x43000000 ${fexfile}; fatload mmc 0 0x48000000 ${kernel}; bootm 0x48000000
<shineworld> extraargs=rootwait init=/init mac_addr=00:AE:99:A3:E4:AF
<shineworld> fexfile=script.bin
<mnemoc> calris: so no one should use his fork
<calris> Oops
Dave77 has joined #linux-sunxi
<ssvb> Turl: finally it has finished :) the PRNG accelerator seems to pass TestU01 'Crush' test -
<calris> I meant the linux-sunxi report
<ssvb> Turl: but I would not dare to run 'BigCrush', as it is going to take an order of magnitude more time
<shineworld> mnemoc, I found script.fex stored in nanda of cubieboard (pre-build image) too much different vs what used for cubie in linux-sunxi
<calris> Which repo should I be hacking on? It looks like hno's is closest to be merged with mainline u-boot
<calris> But is it stable enough?
<mnemoc> calris: hno maintains linux-sunxi's u-boot-sunxi. mostly the sunxi-current branch (dev)
<mnemoc> his own fork is for experimental stuff
<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> mnemoc, in that path you can compare two fex. one from today made kernel for cubie-android (with bsp) and 2nd from nanda of a new cubieboard
<oliv3r> shineworld: that a unified diff?
<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'
<mnemoc> shineworld: time
<oliv3r> shineworld: diff -u file1.fex file2.fex | curl -F 'sprunge=<-'
<ssvb> oliv3r: yes, I took Turl's pasted PRNG code and ran it through (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 ;)
<shineworld> also mali_clkdiv is different
<oliv3r> shineworld: also could you boot nanda (so whatever came with it) and run
<oliv3r> that should fill in the dram_para
<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?
<shineworld> root@android:/ # busybox chmod +x a10-meminfo-static
<shineworld> root@android:/ # ./a10-meminfo-static
<shineworld> dram_clk = 480
<shineworld> dram_chip_density = 4096
<shineworld> dram_type = 3
<shineworld> dram_rank_num = 1
<shineworld> dram_io_width = 16
<shineworld> dram_bus_width = 32
<shineworld> dram_cas = 6
<shineworld> dram_zq = 0x7b
<oliv3r> mnemoc: your to late!
<shineworld> dram_odt_en = 0
<shineworld> dram_tpr0 = 0x30926692
<shineworld> dram_tpr1 = 0x1090
<shineworld> dram_tpr2 = 0x1a0c8
<shineworld> dram_tpr3 = 0x0
<shineworld> dram_emr1 = 0x0
<shineworld> dram_emr2 = 0x0
<shineworld> dram_emr3 = 0x0
<mnemoc> oliv3r: side effect of usng a low prio thread :
<mnemoc> :|
<oliv3r> mnemoc: low prio thread?
<oliv3r> shineworld: it's exactly the same, e.g. they haven't changed it
<mnemoc> here on irc. zero-thinking activities only
<oliv3r> mnemoc: oh, nerd comment :p it's ok, i'm watching tv atm :)
<shineworld> sorry ...
<mnemoc> oliv3r: :)
<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 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
<shineworld> to be more close to realty
<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 :)
<shineworld> shineworld> boot_mmc=fatload mmc 0 0x43000000 ${fexfile}; fatload mmc 0 0x48000000 ${kernel}; bootm 0x48000000
<shineworld> <shineworld> extraargs=rootwait init=/init mac_addr=00:AE:99:A3:E4:AF
<shineworld> <shineworld> fexfile=script.bin
<oliv3r> i do see a new parameter, [boot_disp]
<shineworld> I've put in uEnv.txt
<oliv3r> shineworld: ah! your mac_addr, how did you get htat, did you get that with your cubie?
<shineworld> but someone say me to recover the CPU ID and use to create mac (I don't know how at moment)
<oliv3r> shineworld: interesting, who said that?
<shineworld> I'm searching ....
<mnemoc> oliv3r: 95% moved. still sleeping in the old
<mnemoc> and going there now
<oliv3r> mnemoc: ok, sleep well :)
<mnemoc> you too. good night
<oliv3r> shineworld: i probably told you that, that we COULD do that in the future :p
<oliv3r> shineworld: so you used a rando mac_addr
<shineworld> 20:49 <wingrime> shineworl: everey a10 have unical number
<shineworld> 20:49 <wingrime> can be readen from reg
<shineworld> at moment I will write a uEnv.txt for every board
<shineworld> because I need to create MAC:IP rule in factory router
<shineworld> the optimum should be gain a MAC using CPU ID
<mnemoc> the SID thing is zero in all the A10's I've touched
<shineworld> ACTUALLY, for the law, the MAC address MUST be purchased by a certified seller
<shineworld> we have purchased a little stock (1000) last year
<shineworld> so I can use them
<mnemoc> shineworld: eeprom on the twi0 is probably the most civilized way to get the MAC... if you are making a product and buying addresses
<shineworld> could be :)
<shineworld> or write a tool which modify the uEnv.txt on board :)
<shineworld> just a speculation
<shineworld> but eeprom is good idea
<mnemoc> nand's u-boot doesn't support uEnv.txt/boot.scr
<shineworld> uh... I've missed that
<shineworld> since 1st day I've worked to move on SD and now I'm thinking in that way
<shineworld> but SD is very slow
<shineworld> just to simplify the development time
<mnemoc> in nand you need to modify u-boot's env on a raw partition. called misc iirc
<mnemoc> but I need to return (old)home now. bye. cu tomorrow
<shineworld> my mnemoc and thank you for sharing
<shineworld> *by
shineworld has quit [Remote host closed the connection]
<oliv3r> shineworld: if your building something from scratch; sata is also an option :)
<oliv3r> shineworld: but mmc is actually faster for some people nand is really slow
drachensun has quit [Remote host closed the connection]
<oliv3r> ssvb: that test ran for 10 hours? ouch
<ssvb> oliv3r: this particular test takes ~1.7 hours on 1.7 GHz Pentium 4 according to
<oliv3r> ssvb: then 10 hrs isn't TOO bad
<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
torindel has joined #linux-sunxi
<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
paulk-desktop has quit [Quit: Ex-Chat]
user has left #linux-sunxi ["Leaving"]
eebrah has quit [Ping timeout: 245 seconds]
n01 has quit [Ping timeout: 252 seconds]