Night-Shade has quit [Read error: Network is unreachable]
Night-Shade has joined #linux-sunxi
physis has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
Renard has quit [Remote host closed the connection]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
physis has joined #linux-sunxi
physis has quit [Ping timeout: 240 seconds]
akazien has quit [Remote host closed the connection]
akazien has joined #linux-sunxi
akazien_ has joined #linux-sunxi
akazien has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
Gerwin_J has quit [Quit: Gerwin_J]
egbert has joined #linux-sunxi
wens has joined #linux-sunxi
<wens>
nice, datasheets for a80 related ICs
<wens>
rafaelMOD: afaik there really isn't anyone working on a23
<wens>
i have mainlined what i can by porting drivers from earlier socs
<wens>
great, the ac100 doc even explains rsb
popolon has quit [Quit: WeeChat 1.0.1]
lerc has joined #linux-sunxi
viccuad has quit [Read error: Connection reset by peer]
Wizz_ has quit [Quit: Wizz_]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<rafaelMOD>
wens, thanks
FreezingCold has quit [Ping timeout: 240 seconds]
sehraf has joined #linux-sunxi
<wens>
mripard: i think we can use sun6i's prcm driver for sun9i, until documents are released
<wens>
have to change the clk offsets though
<wens>
but the first few gates should be the same
sehraf has quit [Ping timeout: 246 seconds]
sehraf has joined #linux-sunxi
rafaelMOD has quit [Quit: Leaving]
FreezingCold has joined #linux-sunxi
leviathanch has joined #linux-sunxi
montjoie1home] has quit [Quit: leaving]
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #linux-sunxi
leviathanch has quit [Ping timeout: 244 seconds]
leviathanch has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
leviathanch has quit [Ping timeout: 245 seconds]
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
montjoie[home] has joined #linux-sunxi
leviathanch has joined #linux-sunxi
bengal has joined #linux-sunxi
wens has quit [Quit: leaving]
wens has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
mmarker has joined #linux-sunxi
mmarker has quit [Remote host closed the connection]
jemk has joined #linux-sunxi
mmarker has joined #linux-sunxi
leviathanch has quit [Ping timeout: 258 seconds]
esperegu has joined #linux-sunxi
bonbons has joined #linux-sunxi
Renard has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
esperegu has quit [Ping timeout: 258 seconds]
leviathanch has joined #linux-sunxi
deasy has joined #linux-sunxi
pirea has joined #linux-sunxi
<pirea>
uEnv is necesary to boot?
bertrik has joined #linux-sunxi
nove has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 250 seconds]
FunkyPenguin has joined #linux-sunxi
leviathanch has quit [Ping timeout: 245 seconds]
FunkyPenguin has quit [Ping timeout: 240 seconds]
FunkyPenguin has joined #linux-sunxi
heffer has quit [Ping timeout: 260 seconds]
<mnemoc>
pirea: only if you need to alter the default configuration of a u-boot (configured to support that file) without access to the serial console
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #linux-sunxi
<pirea>
mnemoc tnx :)
esperegu has joined #linux-sunxi
pirea has quit [Quit: Leaving]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
FunkyPenguin has quit [Ping timeout: 255 seconds]
viccuad has joined #linux-sunxi
FunkyPenguin has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 240 seconds]
FunkyPenguin has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #linux-sunxi
<nove>
mripard: you should have said that the video of the previous ELC was already made available
<nove>
mripard: now that i saw it, i understand what you point was about
<nove>
mripard: and in some ways you are right, and i am also in fault because i saw it happen and didn't say anything
<nove>
mripard: but this does not deserve to be labeled with those words, and better description would be
<nove>
mripard: libre(not free, because nobody is here to do gratis labor for nobody else) software enthusiasts that made the decision to prioritize the scant time avaivable by working in only the hardware that they could see that could be used in the full potential.
<nove>
mripard: in few words, maybe "binaries blob haters"
<nove>
mripard: few people can't do everything, so choices was made
<nove>
mripard: and that is understandable
<nove>
mripard: but this is only my opinion.
konradoo77 has quit [Ping timeout: 272 seconds]
konradoo77 has joined #linux-sunxi
viccuad has quit [Read error: Connection reset by peer]
FDCX_ has quit [Ping timeout: 260 seconds]
Black_Horseman has quit [Ping timeout: 260 seconds]
FDCX_ has joined #linux-sunxi
pirea has joined #linux-sunxi
physis has joined #linux-sunxi
<pirea>
mnemoc how to boot an custom os from nand?
<pirea>
like archlinuxarm
ricardocrudo has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 265 seconds]
FunkyPenguin has quit [Ping timeout: 265 seconds]
FunkyPenguin has joined #linux-sunxi
konradoo87 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 272 seconds]
<libv>
pirea: did you try looking at our wiki?
montjoie[home] has quit [Ping timeout: 244 seconds]
<paulk-aldrin>
libv, hey there, did you get my package btw?
<hramrach_>
anybody tried looking at making CedarX output properly work with X?
<nove>
hramrach_: isn't CedarX the name of the proprietaries gpl violating binaries globs?
<nove>
hramrach_: who wants to waste its time making that working?
<nove>
hramrach_: or you were referring to the video engine hardware, that is named cedar video engine?
<hramrach_>
I am referring to the engine. is it named without the X?
* hramrach_
also has a Cedar graphics card
<nove>
hramrach_: it is what is called in the /dev/cedar_dev driver, but there appear to be some comfusing even in allwinner
<hramrach_>
anyway, is cedar linked with the scaler or is there a known way to output the video elsewhere?
<jemk>
A20 user manual calls the video engine Phoenix
<nove>
hramrach_: as the a20 datasheet, is phoenix
<hramrach_>
that's not helping much. I am sure there is a bucketful of stuff called phoenix already
<hramrach_>
I had a few PCs with Phoenix BIOS for one
<nove>
hramrach_: this video engine only outputs the frame to memory, it the display engine task to show it
<jemk>
hramrach_: if you refer to puneets problems, he got everything explained by mittorn on github already and also some example code, but he wants a working solution...
<hramrach_>
I did not see that explanation
<hramrach_>
would be nice to put pointer in the Cedrus page for anyone else who wants to look into this
<hramrach_>
seems to come up from time to time
pwhalen has quit [Ping timeout: 272 seconds]
konradoo77 has quit [Ping timeout: 255 seconds]
afaerber_ has joined #linux-sunxi
<hramrach_>
it's not that it is not useful to have proper output but there is still a lot to do for the actual decoding and the current output works well enough for testing and even video playback
<nove>
hramrach_: the software isn't ready, what else do you want us to do?
afaerber has quit [Ping timeout: 260 seconds]
<hramrach_>
if that explanation on github is worthwhile for somebody trying to fix the output just put a link somewhere obvious
pwhalen has joined #linux-sunxi
<hramrach_>
I wanted to look at 10bit decoding but never got to it :/
pwhalen has quit [Ping timeout: 258 seconds]
pwhalen has joined #linux-sunxi
montjoie[home] has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
cubi_ has joined #linux-sunxi
<cubi_>
ssvb error at linking -lrt lima-memspeed
<ssvb>
cubi_: what is the exact error message? and what is your distro?
<hramrach_>
well, the one on which it fails for me is olinuxino a10s which is quite exotic
<ssvb>
hramrach_: do you have some other devices, where it does not fail easily?
<hramrach_>
never tried anything but the A10s tbh
<hramrach_>
hmm, need to shuffle some cables to get screen output
<ssvb>
pirea: and most importantly, don't forget to report back the results of your findings :-)
<ssvb>
pirea: we have a lot of theoretical knowledge about the DRAM controller, but don't have enough experimental data to confirm everything
<ssvb>
pirea: increasing dcdc3 voltage (which can be checked by running "dmesg | grep buck3") improves dram reliability and allows to use higher clock speeds
<ssvb>
pirea: having it around 1.30V or 1.35V is the reasonable limit (the datasheets seem to specify 1.4V is the absolute maximum)
<ssvb>
pirea: which u-boot are you using?
<nove>
i wanted to spend this weekend to continue learning howto to write a v4l driver, but appears to be impossible to focus
<nove>
as it says in random forum (just quote, i am tried of pasting urls)
<nove>
"And the reverse engineering attempts are not as successful as it sounds in the WiKi"
<nove>
what to think of this? i am not here to fool nobody
<nove>
What is this reality that i am uncapable of seeing, what are the lies that are in the wiki?
<nove>
because i don't know what to do.
<nove>
this really makes me wonder for why and for who i am here wasting my time,
<nove>
end of drama, see you maybe next month
nove has quit [Quit: nove]
<ssvb>
nove: just provide these guys with a link to the github bugtracker
<ssvb>
this is the only way to deal with these people
<ssvb>
they may have troubles setting up and configuring their system right, and the information in the wiki may be missing some important troubleshooting bits
afaerber_ is now known as afaerber
<ssvb>
jemk: I hope you are not so easy to be discouraged as nove :)
konradoo77 has joined #linux-sunxi
rafaelMOD has quit [Remote host closed the connection]
<hramrach_>
ssvb: a10 cubieboard works (no grayscreen)
<ssvb>
hramrach_: thanks, I'll try it on my a13 board later, though I don't have spare time for in-depth debugging this issue
<ssvb>
libv: do you happen to know if the revision of mali400 mp1 hardware is identical in all a10/a10s/a13 devices?
<ssvb>
hramrach_: this kind of poorly reproducible bugs is the hardest to debug
<hramrach_>
hmm, I can test on a13 tablet I guess
<hramrach_>
it even has built-in screen :)
<hramrach_>
and it works on a13 tablet and a20 CT
<ssvb>
hramrach_: hmm, could it be some subtle hardware reliability issue which gets easily exposed on your a10s?
<ssvb>
hramrach_: like the bad memory timings or voltages
<hramrach_>
the a10s has obviously some reliability issues with the memory voltage
<hramrach_>
but then again it happened several times in a row
<hramrach_>
the CT has some obvoius reliability issues too
<ssvb>
yeah, it would help if you could try some very conservative settings on a10s and apply all the fixes on a10s
<ssvb>
hmm, what kind of CT issues?
<hramrach_>
like it crashes and locks up
<hramrach_>
iirc last thing I tried on it was FAST_MBUS in u-boot
<ssvb>
hramrach_: in lima-memtester? or just on some other workloads?
<hramrach_>
apt-get
<hramrach_>
not in memtester
<hramrach_>
idling even. or dhclient when cable is reconnected
<ssvb>
so it runs fine in lima-memtester program but fails with apt-get?
<hramrach_>
it crashes at random
<hramrach_>
I tried only enough of memtester to see the cube
<ssvb>
please run it a bit longer
<hramrach_>
presumably it would crash sooner or later .. unless it's a cpufreq issue
<ssvb>
my current assumptions are that lima-memtester is the strongest dram reliability test, if you get failures in real programs which are not detected by this test - then this is really bad
<ssvb>
hramrach_: just type the commands listed at the end of my e-mail
<hramrach_>
I will assume FAST_MBUS as culprit for now
<ssvb>
hramrach_: and it is safer/better to use the "performance" cpufreq governor to avoid using other cpufreq operating points and transitions between them
<hramrach_>
if it was cpufreq I can always try newer kernel
<ssvb>
hramrach_: FAST_MBUS problems should be easy to be detected by lima-memtester
<hramrach_>
yes, it can just take some time
<hramrach_>
it does not like crash right away
<hramrach_>
sometimes it does but not always
<ssvb>
hramrach_: please spend some time on identifying what's wrong with your CT, this may also help other people
<hramrach_>
yeah, was like intending to fix it sometime
<hramrach_>
but not much use for it atm anyway
<hramrach_>
cube spinning away ...
<ssvb>
hramrach_: just start lima-memtester and let it run overnight on your CT
<ssvb>
hramrach_: it will either survive until the Morning or not :-)
<hramrach_>
btw the apt workload may use dma which is not tested by lima-memtester
<hramrach_>
and once I had a system that would run memtest86 for a day without a glitch and crash within a few minutes of heavy disk usage
<ssvb>
lima-memtester is stressing competing accesses to dram from multiple ports, the dma use case may be also somewhat covered by this
<ssvb>
but please first run the tests, and then we can speculate later ;-)
<hramrach_>
yes, can just keep cube running
<ssvb>
yeah, thanks
<hramrach_>
not sure there is much meaningful difference between spinning a cube and reading a sd card on a10
konradoo77 has quit [Ping timeout: 246 seconds]
<hramrach_>
or a20
pwhalen has joined #linux-sunxi
<ssvb>
hramrach_: are you using the stock 432MHz dram settings on your CT and the updated script.bin with 1.3V dcdc3 voltage?
<hramrach_>
I think it's the stock setting completely
<ssvb>
what does "dmesg | grep buck3" say on your CT?
konradoo77 has joined #linux-sunxi
MY123 has joined #linux-sunxi
<hramrach_>
nothing. the CT became a bit unresponsive as a result of running the memtester
<ssvb>
hramrach_: maybe after the lima-memtester run
<ssvb>
hramrach_: this kind of problems is supposed to be reliably detected by lima-memtester, if not - then the test program is apparently not good enough :-(
<hramrach_>
yes, the installation is old
<ssvb>
it is a known bad configuration, hence the reliability problems are not surprising at all
<hramrach_>
Linux 3.4.75+ #12 SMP PREEMPT Mon Feb 3 20:12:31 CET 2014 armv7l GNU/Linux
<hramrach_>
it worked well enough before. probably before fast_mbus
<ssvb>
it has both fast_mbus and also cpufreq problems
<hramrach_>
how is the cpufreq problem diagnosed by running while true shell loop? is the binary linking/startup time long enough for the cpu to drop to lower state?
<ssvb>
the md5 hashes may be reported as different values because of data corruption
<ssvb>
people from that forum thread were unlucky enough to use an SD card image from a guy who decided that it is a good idea to provide 1.2GHz CPU overclocking out of the box
<hramrach_>
I wonder what I clock it
pwhalen has quit [Ping timeout: 244 seconds]
<hramrach_>
912MHz
<hramrach_>
so not overclocked but still fails under load
<ssvb>
just try to run all the reliability tests and confirm that they can detect problems
<ssvb>
then upgrade script.bin and test everything again
<ssvb>
and considering that I even have some difficulties convincing you to run tests, the situation is likely almost hopeless for the average users...
bertrik has quit [Remote host closed the connection]
<hramrach_>
I know it's broken, no need to run test to confirm ;-)
<hramrach_>
just crashed again. in scheduler when I pause and restarted memtester so that I could run another command
<ssvb>
but be need to test the tests! :-)
<ssvb>
to be sure that they can actually detect shit
<hramrach_>
:)
<hramrach_>
this reset button on CT is really helpful :)
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
pwhalen has joined #linux-sunxi
<hramrach_>
hmm, I set up a memtester restarter like while true ; do killall -STOP lima-memtester ; sleep 1 ; killall -CONT lima-memtester ; sleep 3 ; done
<hramrach_>
crashes really fast
<hramrach_>
now I have a test that reliably detects the problem but have yet to find what the problem is
<ssvb>
hramrach_: replace the script.bin with a new one, then try again
konradoo77 has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
montjoie[home] has quit [Ping timeout: 246 seconds]
montjoie[home] has joined #linux-sunxi
<hramrach_>
something went wrong with my leds. the green one is always on :/
<hramrach_>
hmm, wrong fex patching
<ssvb>
patching?
<ssvb>
why not just taking the fex as-is from the sunxi-boards repo?
<hramrach_>
because the default led settings are annoying
<hramrach_>
anyway, the restarter is running for a while so using the updated dvfs table and/or buck3 seems to improve stability
Renard has quit [Ping timeout: 240 seconds]
Renard has joined #linux-sunxi
popolon has joined #linux-sunxi
nicksydney_ has quit [*.net *.split]
nicksydney has joined #linux-sunxi
cyanorose has joined #linux-sunxi
mmarker has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
pwhalen has quit [Ping timeout: 255 seconds]
konradoo77 has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
pwhalen has joined #linux-sunxi
wickwire has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
w00tc0d3 has joined #linux-sunxi
w00tc0d3 has quit [Changing host]
RzR is now known as rZr
pwhalen has quit [Ping timeout: 244 seconds]
cyanorose has quit [Remote host closed the connection]
pwhalen has joined #linux-sunxi
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 246 seconds]
netlynx has quit [Quit: Leaving]
MY123 has quit []
Black_Horseman has joined #linux-sunxi
jemk has quit [Quit: leaving]
viccuad has quit [Read error: Connection reset by peer]