<akaWolf>
hi guys! can you help me? I'm using mali lib and I've got «Error: eglInitialize failed» with «EGL_BAD_ALLOC»
<akaWolf>
hmmm
hipboi has joined #linux-sunxi
Mormegil has joined #linux-sunxi
<Mormegil>
Hi! I tried to clean up the formatting of the [[Boot Android from SdCard]] wikipage but the spamfilter stopped me, pointing me here... Anyone could help?
<NiteHawk>
Mormegil: could you try again, please? :)
FDCX has joined #linux-sunxi
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
<Mormegil>
NiteHawk: Yep, works now, thanks.
<NiteHawk>
Mormegil: yw
avph has quit [Ping timeout: 246 seconds]
Mormegil has quit []
avph has joined #linux-sunxi
<NiteHawk>
turl: maybe spam filtering (akismet?) is a bit too paranoid currently?
<tkaiser>
gusenkovs: Do you really play around with any of SinoVoip's 4.x kernel forks?
SadSmile has quit [Quit: Leaving]
<apritzel>
montjoie: what about "sun8i-emac" as the generic name in your driver and then every SoC can use a more specific name in addition in case it needs specific settings/fixes/workarounds?
cnxsoft has quit [Remote host closed the connection]
<montjoie>
apritzel: for a general name I agree, but all binding name I see have always 3 part
diego_r has quit [Remote host closed the connection]
vishnup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<apritzel>
then it's time to deviate ;-)
<KotCzarny>
uh oh
kill_-9_1 has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
MY123 has quit [Disconnected by services]
kill_-9_1 is now known as MY123
Ueno_Otoko has quit [Ping timeout: 246 seconds]
JohnDoe0 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
reinforce has joined #linux-sunxi
vishnup has quit [Remote host closed the connection]
JohnDoe0 has quit [Ping timeout: 248 seconds]
domidumont has quit [Read error: Connection reset by peer]
JohnDoe0 has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Client Quit]
IgorPec has joined #linux-sunxi
JohnDoe0 has quit [Ping timeout: 246 seconds]
JohnDoe0 has joined #linux-sunxi
yann||work has quit [Ping timeout: 248 seconds]
mzki has quit [Quit: leaving]
<plaes>
tkaiser: yeah.. he does
p1u3sch1_ has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
montjoie has quit [Ping timeout: 248 seconds]
montjoie has joined #linux-sunxi
Andy-D has joined #linux-sunxi
vagrantc has joined #linux-sunxi
nove has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
khuey|away is now known as khuey
<wens>
montjoie: sun8i-emac should be fine
<wens>
i don't recall any drivers specifically having the soc name in the driver name, other than the clk and pinctrl ones
<Turl>
compatibles do, but for drivers you're usually fine naming them sunNi-stuff
<vagrantc>
wens: i was looking at your A80 branches and wondering if any of the branches had working smp, usb and network? or would i have to cobble them together by cherry-picking all the branches together?
<wens>
montjoie: i also did a bunch of cleanup on your driver, though haven't tested it
<wens>
vagrantc: usb is mainlined already
<vagrantc>
that's a start :)
<wens>
cc-a80 usb support is pending though, due to its awkward design
<wens>
network and wifi are both in my sun9i-wip branch
<wens>
smp probably won't get mainlined
<vagrantc>
ouch.
<wens>
we prefer psci support in u-boot
<vagrantc>
any recent u-boot branches for cubieboard4? only one i could find was ancient...
mossroy has joined #linux-sunxi
<vagrantc>
wens: and thanks for all your work on this
<wens>
vagrantc: u-boot work hasn't progressed much
* vagrantc
tried cherry-picking the smp patches, and was surprised they applied fine, but the failed to compile
<apritzel>
is PSCI support for a new AW SoC so complicated in U-Boot?
<apritzel>
I'd guess it's just a matter of configuration, isn't it?
<wens>
apritzel: not really, but u-boot support for a80 is so minimal right now
<wens>
so there's a bunch of stuff to do before we get to PSCI
<wens>
like PMICs, MMC, USB(?)
<apritzel>
Ah, OK, so there is only some vendor U-Boot available atm?
<wens>
yeah, pretty much
<wens>
it seems not many people are still interested in the a80
p1u3sch1 has quit [Ping timeout: 246 seconds]
p1u3sch1 has joined #linux-sunxi
<apritzel>
but it looks to be pretty capable, 4 * A15@2GHz plus USB3 plus much RAM
<jemk>
no, i use master with d33de20 cherry-picked
<jemk>
same result with a64 branch + d33de20
<ssvb>
ok
<ssvb>
are you setting ".scratch_addr = 0x11000" though?
<jemk>
no, 0x12000 as in you patch
<ssvb>
not sure if it will help, but maybe try it too
<jemk>
i tried, didn't change
<ssvb>
it looks like it makes sense to add a lot of debugging prints to the code to check where it fails
<jemk>
but after adding a lot of debug prints i now always get to "mmu not enabled"
<jemk>
looks like delays improve things...
<ssvb>
maybe some barriers are missing?
<jemk>
now it fails at the buffer swapping
<jemk>
wrong
<ssvb>
when modifying some coprocessor registers?
<KotCzarny>
apritzel, wens: how much work would it require to move hw init (psci as you say) from 'bootloader' to linux kernel?
<ssvb>
jemk: also try to "ping" fel periodically just to check where exactly it fails
doppo has joined #linux-sunxi
<KotCzarny>
not to bash on u-boot, but it kinda pins the hw to bootloader
<ssvb>
jemk: if one of the fel requests is identified as non-responding, then it's likely the previous one that has messed up things
<ssvb>
KotCzarny: do you want to merge the bootloader and the linux kernel into a single monolithic thing?
<jemk>
ssvb: now it fails again at reading dacr cp reg, last working was read ttbcr
<KotCzarny>
ssvb, nope, bootloader only has to know where and how to load kernel and start it
<KotCzarny>
though in similar vein bios on x86 provides acpi map about stuff (and smp too)
<ssvb>
KotCzarny: in other words, you want something like just the SPL which directly starts the linux kernel and skips the main U-Boot part
<KotCzarny>
ssvb, seems so, and add hw init drivers to kernel
<jemk>
ssvb: this is reproducible, either it fails there or when writing the spl to 0x12000-0x15c00
<ssvb>
KotCzarny: by the way, PSCI is also not strictly necessary and you can bring up additional cores in the Linux kernel directly (there is even old deprecated sunxi code for that in the kernel code)
<ssvb>
KotCzarny: but I don't quite understand what you are trying to achieve (other that just having fun and figuring out how these things work) :-)
<ssvb>
jemk: I suspect some sort of coherency issues
<KotCzarny>
ssvb, just wondering if it would be possible to have full hw detection/init in kernel
<ssvb>
KotCzarny: of course it is technically possible, but PSCI had been introduced for a reason
<KotCzarny>
uhum
<ssvb>
jemk: for example, if the "fel write" operations which write ARM code to SRAM scratch buffer are not properly synchronized with "fel exec"
<ssvb>
jemk: we may need to review the caches setup and possibly add barrier instructions
keesj has joined #linux-sunxi
<keesj>
lo
<keesj>
I am trying to enable spi (2) on an A10-OlinuXino-LIME board and failing at randomly changing stuff in the dts
<KotCzarny>
ssvb, one of the reasons to have detection in kernel would be being able to boot one image on different devices
<ssvb>
but the distribution maintainers did not seem to be interested in using this opportunity
doppo has joined #linux-sunxi
<ssvb>
IgorPec: ^ if I understand KotCzarny correctly, you now trying to create unified sd card images?
<IgorPec>
ssvb: we were trying to do for H3 boards and we came out with two
<ssvb>
IgorPec: yes, with some adjustments we can have a unified A10/A13/A20/H3 image to support a set of boards
<IgorPec>
ssvb: that would be really nice
<ssvb>
either automatically making the decision (take the DRAM size into account and read some GPIO or check the USB bus for built-in USB devices/hubs)
<ssvb>
or simply asking the user after booting in a "failsafe" configuration (this is what the current sunxi-bootsetup demo does)
<IgorPec>
auto detect is hard to achieve
<ssvb>
well, if we don't claim a fully universal image, then it is easy
<IgorPec>
in this case yes
<ssvb>
for example, you can have a unified Cubieboard1/Cubieboard2/Cubietruck image with full autodetection and no need to ask the user
<IgorPec>
CB1 too?
<ssvb>
yes, of course
<ssvb>
the decision can be made just based on the RAM size and the SoC type
<IgorPec>
and bananas can also be added
<ssvb>
well, this is where it becomes difficult
<ssvb>
differentiating cubieboards and bananas can be tricky without asking the user
<ssvb>
if there are two boards using the same soc type and the same dram size, then how the installer would be able to see the difference between them?
<IgorPec>
gmac / emac?
<ssvb>
how do you suggest to probe for this information?
<IgorPec>
don't know ;)
<IgorPec>
you mean from uboot?
<ssvb>
from anywhere
<ssvb>
let's say, you can run a bare metal code on the device
<ssvb>
how can you probe for the gmac availability?
<ssvb>
especially considering that it may need to be powered up via some gpio which may be different between different boards
<IgorPec>
power on, check response, go further .. ?
<ssvb>
"power on" as in "write to some gpio which may or may not be used to power up gmac"?
<ssvb>
this is dangerous because it may potentially damage the hardware
<IgorPec>
this would need to be checked
<ssvb>
how?
<ssvb>
the users may run this code on some board where this particular gpio is used for something else
<IgorPec>
ok, let's forget this
<IgorPec>
then user input is a must
<keesj>
(sorry to join in) I just read ssvb's message on the list. As a user it is not uboot (detection) that will stop me. While not perfect the debian jessie "sd install" method did work for me ( and I think also would work for average users) it is quite a hack but... does work https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_from_an_SD_card_image
<IgorPec>
so we can boot one image on all boards give user a select box and install proper uboot / kernel
<ssvb>
keesj: it is not a hack because the "failsafe" configuration relies on the use of the peripherals, which are also used by the boot ROM
<tkaiser>
IgorPec: And trust me, there will be some that choose the wrong board and blame you afterwards ;)
<keesj>
doesn't mean you need to use different u-boot (you might want to use the same binary if possible)
<ssvb>
keesj: for example, the boot ROM can read the SD card when booting from it
<IgorPec>
tkaiser: that's solved with "are you sure" "please type "YES I agree" ... :)
<Wizzup>
keesj: what kernel are you using on the lime?
<Wizzup>
I have spi working on the lime a10 I think
<ssvb>
keesj: this fact *ensures* that the SD card can be safely used on all Allwinner devices in a generic way
<apritzel>
KotCzarny: PSCI has been exactly introduced to make a single Linux kernel work on several devices
<apritzel>
to have support for every single board specific crap in the kernel
<apritzel>
having PSCI in U-Boot was more of a hack because there is no other firmware available for sunxi devices mostly
<ssvb>
IgorPec, tkaiser: and of course, the user can't select an obviously incompatible device (if the installer is run on an A10 hardware, then A20 boards are not listed in the selection box)
<apritzel>
this is different now with the Pine64, where we have ARM Trusted Firmware for this
<apritzel>
This provides the PSCI bits and U-Boot is just what is says on the tin: a boot loader
mosterta has joined #linux-sunxi
<tkaiser>
ssvb: thx, we're looking into this more closely
<IgorPec>
yes
<tkaiser>
Since board auto detection with already running kernel is more or less PITA and might always break in the future
<longsleep>
tkaiser: you think i should revert the Pine64 dts cooler table changes so more checks can be made regarding voltage in dvfs table?
<tkaiser>
longsleep: as far as I understand it would be the best to be able to disable throttling in the 3.10.65 kernel to be able to run cpufreq-ljt-stress-test really at the intended clockspeeds
<tkaiser>
ssvb: Using cpufreq-ljt-stress-test on SoCs with this budget cooling stuff isn't that easy anymore
<tkaiser>
cpufreq-ljt-stress-test tries to test 1200 MHz while the kernel throttled down to 816 MHz
<longsleep>
even when setting the govenor to performance"
<longsleep>
?
<tkaiser>
cpufreq-ljt-stress-test sets it to userspace and throttling always wins
<tkaiser>
So either 200¡C in the cooler table or disabled throttling or a powerful fan on top of a huge heatsink ;)
<longsleep>
well running with 1152.00 GHz at 1.3V does is around 50C for my pine
afaerber has joined #linux-sunxi
<longsleep>
without doing anything
<longsleep>
this is the first time i even look at throttling and temperature, so please forgive me if i ask stupid questions :)
<tkaiser>
Without heatsink?
<longsleep>
yes no heatsink
<longsleep>
idle at 4800GHz is around 45C
<tkaiser>
Sounds reasonable (especially the 4.8THz ;)
<longsleep>
err
<longsleep>
that would be hell of a soc
<tkaiser>
But if you run 4 threads cpuburn-a8 or cpuburn-a53 this _will_ change
<tkaiser>
And for me it's close to impossible to start cpuburn-a53 with high scaling_max_freq since the Pine64 immediately deadlocks
<longsleep>
ok thats a start for improvment then
<longsleep>
finding settings / fixes which make that work
<tkaiser>
longsleep: IMO it's already over. As soon as people realise that 1536MHz are possible with A64 they will start to try to use this. Same story as with H3 back then
<longsleep>
hehe - well noone needs to build images with that setting
<longsleep>
i could even reduce the max value in kernel
<longsleep>
i guess joe average does not succeed building an arm64 kernel nowadays
<tkaiser>
They clone your repo and follow your instructions? ;)
<longsleep>
mhm - still requires some talent
<longsleep>
and all my instructions require linux in the first place
<longsleep>
i sill feel pretty save from the random dudes
<tkaiser>
'Unlocking' the 1344 MHz was just dtc/vi/dtc ;)
bonbons has joined #linux-sunxi
<longsleep>
lets see what ssvb's cpuburn-arm does to my pine
<jemk>
ssvb: i'll give up for today, but will try again
<jemk>
ssvb: it always fails at reading the result after executing the code to read DACR.
<jemk>
if that works sometimes, it fails in the spl_thunk somewhere in/after swapping the buffers
<ssvb>
jemk: I still suspect coherency issues, which means that the self-modifying code may be somewhat problematic on A80
<tkaiser>
longsleep: While running how many threads what in parallel? cpuburn-a8? cpuburn-a53?
jelly-home has joined #linux-sunxi
<longsleep>
did not run anything else :D
<tkaiser>
longsleep: Then on a SMP machine pretty useless. We have to adjust the wiki article since the most important part is overseen: "There are border cases in which extended tests show a device might not be stable at certain settings even though they pass the tests in this script. Especially on a multi-core system you may want to run CPU-intensive tasks in the background while running cpufreq-ljt-stress-test in order to keep all
<tkaiser>
cores busy. The cpuburn scripts (see below) or compiling a kernel might be suitable tasks for this end."
<longsleep>
got it, now how do i compile the .S files in there, gcc gives only errors
<ssvb>
longsleep: can you paste these errors?
<tkaiser>
cross-compile like this: "arm-linux-gnueabihf-gcc -static -o cpuburn-a8 cpuburn-a8.S"?
<longsleep>
err yeah, i probably did run it wrong
<tkaiser>
ssvb: I had also troubles to build it in Pine64 directly
<longsleep>
gcc version 5.3.1 20160225 (Ubuntu/Linaro 5.3.1-10ubuntu2)
<jemk>
ssvb: im getting mad. wrote 100 zeros after the code, and thought it works now. BUT it also works after removing the write again...
<apritzel>
ssvb: the A80 is a dual cluster SoC, so coherency is different from the other SoCs
<longsleep>
ssvb: cpuburn-a53.S compiled just fine same command
<longsleep>
tkaiser: i have now 4 cpuburn-a53 running not crashing
<longsleep>
temp alread at 73 C :)
<apritzel>
ssvb: does it work on the A83T? (also dual cluster)
<ssvb>
longsleep: sure, because cpuburn-a53.S has both 64-bit and 32-bit implementations and cpuburn-a8.S only has 32-bit ARM assembly
<GeneralStupid>
hey
<GeneralStupid>
i pulled a new git revision and it does not buil
<ssvb>
apritzel: I have no A83T hardware
<GeneralStupid>
libvdpau-sunxi..
<longsleep>
ssvb: ah then the 64bit compiler cannot build it
<jemk>
ssvb: it only worked because i had it turned off completely before the test, not only reset
<apritzel>
ssvb: or in general: the A80 has Cortex-A15, do you have any A7 specific code in there?
<ssvb>
jemk: and this smells like we (or the BROM) are not initializing some important system register properly
<jemk>
GeneralStupid: does not build... error message please
<apritzel>
ssvb: some system registers have a subtly different layout between A7 and A15, IIRC
<GeneralStupid>
device.c:23:27: fatal error: cedrus/cedrus.h: No such file or directory
<longsleep>
tkaiser: thermal throttling kicks in now pretty much at once when running ./cpufreq-ljt-stress-test
<GeneralStupid>
smartpointers? in C? is it useful? i would try that lib :)
<jemk>
GeneralStupid: did you compile and install libcedrus?
<jemk>
apritzel: isn't the boot core a A7?
<GeneralStupid>
jemk: is it new?
<apritzel>
jemk: no idea, is it?
<apritzel>
and the FEL code runs completely in UP, right?
<jemk>
GeneralStupid: yes, i'm trying to split the decoding from vdpau to reuse it without vdpau
<tkaiser>
longsleep: You can prevent that by adjusting the cooler table values insanely high. But I would assume they also implement killing of CPU cores so you might end up with just cpu0 left
<jemk>
ssvb: i have to verify, but i think this code is ok. it works perfectly after longer poweroff until i begin loading spls that are big enough to need buffer swaps. then it doesn't work anymore until i remove power
<longsleep>
tkaiser: yes got it - but i can use the cpuburn-a53 to generate load on all cores and see what happens manually
<tkaiser>
longsleep: BTW: Please use this 'grep -c processor /proc/cpuinfo' in your pine64_health.sh instead of the stuff you copied from the RPi-Monitor template
<apritzel>
ssvb: cache are really never off on modern ARM cores
<apritzel>
I know, it's a mess, but ...
<longsleep>
tkaiser: ok
<longsleep>
tkaiser: done, also fixed the THz :)
<apritzel>
ssvb: I reckon the cache layout is different with the dual cluster configuration
<ssvb>
jemk: does everything work seemingly fine after cold boot?
<jemk>
ssvb: no, executing the spl still fails, but as long as no buffer swaps occur it doesn't break the dacr read again
<ssvb>
jemk: you can try to debug the cold boot first in order to make everything a little bit more deterministic
<longsleep>
Who is usually responsible to bring back the cpus, manually works but elsewise they stay disabled.
<ssvb>
longsleep: the 3.4 kernel on H3 also does not seem to bring back the CPUs after they had been killed
<longsleep>
ssvb: well, that is stupid
<longsleep>
i guess some user space tool would be required ..
<ssvb>
we have adjusted the FEX for H3 to make killing off the CPUs only the last ditch effort
<tkaiser>
ssvb: I'm too dumb for ruby but have 2 feature requests for cpufreq-ljt-stress-test: check scaling_cur_freq after setting it and take care whether count of available CPU cores remains the same
matthias_bgg has joined #linux-sunxi
<ssvb>
tkaiser: the cpufreq-ljt-stress-test script was a one evening hack :-)
<tkaiser>
ssvb: encouraging H3 users to let cpufreq-ljt-stress-test run failed always
<ssvb>
yes, we can make something that is more robust and user friendly
<tkaiser>
ssvb: Back then with A10 it was sufficient I would think
<longsleep>
sounds like a good cause to learn ruby @tkaiser :)
<ssvb>
longsleep: nah, we should rewrite this in C, get rid of the dependency on the external libjpeg-turbo package and do everything automagically
<longsleep>
ssvb: thats even better, i had to install ruby just for the script :P
<ssvb>
also unify all the cpuburn programs, so that they just rely on the runtime CPU type detection
<jemk>
ssvb: if i replace first spl-thunk instruction by "bx lr" everything works, a "bx lr" spl fails. so i'll debug the spl-thunk tomorrow, for today i'm out. bye.
<ssvb>
longsleep: as I said, it was just a quick hack, developed when debugging data corruption issue on an A10 Lime board :-)
<tkaiser>
ssvb: The last idea is dangerous for Pine64 users ;) Especially when 1344 MHz are enabled and cpuburn-a53 simply deadlocks the board within milliseconds ;)
<ssvb>
jemk: thanks for your hard work debugging this
<longsleep>
tkaiser: ah, that reminds me - what is the voltage for 1344?
<tkaiser>
longsleep: Good question. Countless hours running cpufreq-ljt-stress-test might tell after playing around with dvfs settings and adding some safety headroom ;)
<ssvb>
tkaiser: the cpuburn program can a) show a big fat warning first explaining possible consequences and b) gradually increase the power consumption instead of running at full blast from the start
<ssvb>
tkaiser: but deadlocking clearly indicates that the hardware is not very robust either way
<tkaiser>
ssvb: Great idea. That's what I already do: Increasing scaling_max_freq
<ssvb>
tkaiser: you mentioned that you had a bad USB cable?
<ssvb>
I also had the same problem, and solved it by replacing a generic standard Micro-USB cable with the cable and the PSU that came with my MSI Primo81 tablet
<tkaiser>
ssvb: Yeah, I have one 'crappy' cable here but now use one that should be rather good (still no Multimeter bought, I stop comment on things which I couldn't measure ;)
<tkaiser>
With the crappy one even running a simple disk benchmark with a host powered SSD led to a deadlock of Pine64
<tkaiser>
cpuburn-a53 is evil :)
<tkaiser>
10 secs after increasing cpufreq to 816 MHz already cpu3/cpu2 killed :)
<longsleep>
tkaiser: do you use the new dts from earlier or the old one?
<tkaiser>
longsleep: An own one: I wanted to play with 1536MHz already ;)
<longsleep>
tkaiser: ok, i might just add additional cpu_budget_cool states to avoid killing cpus so early
<tkaiser>
But only the cooler table changes are recognized but not the dvfs stuff (I tried to play H3 overvolting with 1.5V).
<longsleep>
mhm - sounds like something to investigate :)
<tkaiser>
longsleep: Is the .dtb also used by the BSP u-boot?
<longsleep>
tkaiser: yes
<longsleep>
tkaiser: it seems to use the dtb only, fex file is essentially empty
<ssvb>
the Pine64 board is advertised to have a 1.2GHz CPU, the same as some of the competitors (RPi3 and DragonBoard 410c)
<ssvb>
if the users find out that it is "only" 1152MHz, there might be a riot :-)
<longsleep>
hehe
<tkaiser>
longsleep: What I meant: Is the same file on the 1st partition read or is this part of u-boot/initrd?
<longsleep>
tkaiser: you think it makes a difference when u-boot loads the table?
<tkaiser>
ssvb: Enabling the 1200 MHz by adjusting the cooler table might already work.
<tkaiser>
longsleep: No idea and didn't looked into the sources which part is responsible for what. At least cooler table can be adjusted by manipulating the .dtb on the first partition of your image.
<ssvb>
tkaiser: yes, but then we have to deal with reliability and potential overheating issues
<tkaiser>
ssvb: Sure and A64 behaves not that nice regarding overheating
<tkaiser>
ssvb: But I think the defaults in the BSP are for a virtual tablet device (according to comments therein)