ricardocrudo has quit [Remote host closed the connection]
tomboy64 has quit [Ping timeout: 264 seconds]
libcg has quit [Ping timeout: 240 seconds]
akaizen has quit [Remote host closed the connection]
lemonzest has quit [Quit: Leaving]
hipboi has joined #linux-sunxi
akaizen has joined #linux-sunxi
TheSeven has quit [Ping timeout: 248 seconds]
TheSeven has joined #linux-sunxi
sdschulze has quit [Ping timeout: 248 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 268 seconds]
libcg has joined #linux-sunxi
akaizen has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
medvid has quit [Quit: !]
dlan has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
akaizen has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
medvid has joined #linux-sunxi
medvid has quit [Ping timeout: 260 seconds]
doppo has quit [Ping timeout: 268 seconds]
doppo has joined #linux-sunxi
orly_owl has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
Shirasaka-Hazumi has quit [Ping timeout: 248 seconds]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1_ has joined #linux-sunxi
Shirasaka-Hazumi has joined #linux-sunxi
lennyraposo has joined #linux-sunxi
<lennyraposo>
hi all
IgorPec has joined #linux-sunxi
<lennyraposo>
got all caught up in what I messed today
<lennyraposo>
missed*
<lennyraposo>
never thought to ask susan33 what her end game is for the pine and linux
<lennyraposo>
there is an image that longsleep put together that got video decode going
<lennyraposo>
and plays at 1080p
<lennyraposo>
just hoping it isn't a case of media center with the pineboard as of yet
<lennyraposo>
the board is a WIP
<lennyraposo>
enough of that
<lennyraposo>
hey montjoie
<lennyraposo>
read that you improved upon the mac sitation for the h3
<lennyraposo>
congrats
<lennyraposo>
;)
valkyr1e has quit [Ping timeout: 250 seconds]
valkyr1e has joined #linux-sunxi
_fortis has joined #linux-sunxi
xypron has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<KotCzarny>
longsleep, is it? i thought mainline uboot moved to boot.scr for providing env variables and booting scripting
<KotCzarny>
ssvb, i think there was esgl--gl glue lib somewhere to make gl apps run with esgl libs
reinforce has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<KotCzarny>
i think the name was glshim
<KotCzarny>
glshim is runtime translation from GL 1.x to GL ES 1.x which means openGL games can be run with openGLES-hardware (without modifications, just recompilation).
<montjoie>
lennyraposo: thanks
<KotCzarny>
ahm, recompilation is still needed tho
clonak has joined #linux-sunxi
<KotCzarny>
ssvb, i guess you can add minecraft to 'gl apps' list
<tkaiser>
Is there an easy way to 'translate' this to be used with 2016.03?
domidumont has left #linux-sunxi [#linux-sunxi]
<wens>
accidentally overwrote stock uboot on emmc on my sinlinx boards :|
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
<rellla>
ssvb: it's still not clear to me :)
The_Loko has joined #linux-sunxi
yann|work has joined #linux-sunxi
<rellla>
ssvb: kernel ump driver was modified, that cma is the default backend. libvdpau-sunxi is modified, that every buffer is allocated via ump, so from cma, so max 192MB (or whatever CMA_SIZE is). ok.
<rellla>
ssvb: libvdpau-sunxi now does a ump_reference_add for this ump handle and creates a texture from it with glTexImage2D, which means for me, does a internal memcpy from ump/cma to the GPU accessible memory? <- where is this memory from? or is there just a pointer to the ump referenced?
diego_r has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
kurain has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
<kurain>
I am trying with orangepi-2 with allwinner h3 cpu. but I can't get its speaker work
<kurain>
I am trying it with allwinner 3.4 officially kernel version
The_Loko has joined #linux-sunxi
<kurain>
audio_open_alsa: failed to get hardware parameters from audio device. Inappropriate ioctl for device
<kurain>
this is the issue that it shows up
reev has quit [Read error: Connection reset by peer]
<kurain>
@tkaiser, my fex works with android system, but now I am using Debian instead
lemonzest has joined #linux-sunxi
<matthias_bgg>
apritzel, I saw your new a64 u-boot branch still uses libdram. Are there any issues left with this?
<rellla>
ssvb: i read up, that (some) gl implementation may put the texture data in CPU-only memory if GPU accessible memory is rare during a glTexImage2D. if the (CPU mem) texture is bound again, then it is put into GPU accessible mem again.
<apritzel>
matthias_bgg: if you want to boot with FEL, that's the only option so far
<apritzel>
for the SD boot I use boot0 and can avoid libdram
<apritzel>
despite Allwinner's promises I haven't got any response on our request for the DRAM init code so far
<matthias_bgg>
apritzel, I'm interested in the second, but I don't know which header do I have to add to the u-boot so that boot0 accpets it.
<apritzel>
matthias_bgg: I see, I haven't pushed that part yet, I was planning on having two separate branches for that
<apritzel>
problem is that the creation is a bit manual at the moment
<matthias_bgg>
apritzel, can I find a description somewhere? I was searching, but unable to find anything about this
<apritzel>
no, not yet, but I will push something later
<apritzel>
matthias_bgg: if you want to give it a try, just copy the first 1.5KB of the original U-Boot image and prepend that to u-boot-dtb.img
<apritzel>
after having adjusted the load address to 4a000600
p1u3sch1_ has quit [Ping timeout: 260 seconds]
<matthias_bgg>
apritzel, ok, I will give it a try. thanks a lot
p1u3sch1 has joined #linux-sunxi
<tkaiser>
kurain: Does /proc/cmdline contains something regarding audio? Are you using an OS image from Xunlong?
<rellla>
ssvb: so if mali is doing as i described, i only have to care, that no unnecessary glTexImage2D/memcpy should be done.
<ssvb>
rellla: "the GPU accessible memory" would be some memory allocated one page at a time and registered in the Mali MMU
<NiteHawk>
ssvb: i see, thx. so it should be kept for reference, and may someday replace the "Works everywhere" one (e.g. in case A8 support became obsolete)
<ssvb>
NiteHawk: more like it is a backup solution if the current one proves to be inferior/problematic on some newer ARM processors
<ssvb>
for example, jemk got FEL boot working on A80, but there were some quirks (maybe A15 related, maybe not)
<ssvb>
the A8 support is unlikely to become obsolete any time soon
<NiteHawk>
ah, ok. we could select different code paths based on soc_id in that scenario - i get the idea
<ssvb>
yes
joost_dtn has joined #linux-sunxi
<wens>
i have a A83 MMU patch for sunxi-fel i forgot to post
<ssvb>
wens: thanks, and we should also leave the SRAM area at 0x44000 alone, so that the OpenRISC firmware can use it without clashing with sunxi-fel
<kurain>
@tkaiser, I get this issue, it is caused by CONFIG_SND_SUNXI_SOC_SUPPORT_AUDIO_RAW macro in asound.h
<kurain>
which make the ioctrl SNDRV_PCM_IOCTL_HW_REFINE invalid
<kurain>
for alsa lib built with common kernel header
<kurain>
I am not using os image from Xunlong instead the image built by myself
vishnup has joined #linux-sunxi
<ssvb>
rellla: I would assume that mosterta found a way to interpret or wrap UMP buffers as EGLImageKHR and use glEGLImageTargetTexture2DOES to avoid excessive buffer copies
<ssvb>
but please better talk with mosterta about this
Gerwin_J has quit [Quit: Gerwin_J]
<rellla>
ssvb: i will do. i saw, that my code is wrong if someone wants to do the rendering with vdpau. there is something missing to get the pixels back from the gl texture.
<rellla>
so still enough work to do :p thanks so far
<jemk>
tkaiser: your h3 device is using lpddr3 ram according to dram_type=7, which isn't supported for any sunxi device in mainline u-boot yet
<vishnup>
jemk: lpddr3 support for a83t bpi-m3 is already in mainline u-boot
<jemk>
vishnup: oh, i missed that
<jemk>
i think we should try to merge some of the sun8i dram drivers some day, they all look very similar
vishnu_ has joined #linux-sunxi
vishnup has quit [Ping timeout: 246 seconds]
cnxsoft has quit [Quit: cnxsoft]
tkaiser has joined #linux-sunxi
<tkaiser>
jemk: vishnup: Thx, then I'll have a look how to 'activate' support for LPDDR3
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
<ssvb>
wens: yes, at least unless/until we find a good reason not to do so
doppo has quit [Ping timeout: 246 seconds]
doppo has joined #linux-sunxi
akaizen has joined #linux-sunxi
bwarff_ has quit [Ping timeout: 276 seconds]
<montjoie>
the sun4i-ss corruption get me mad
<ssvb>
montjoie: what kind of board is that?
<montjoie>
For each request I do the same via aes-asm and sometime a got an additionnal corrupt block
<montjoie>
like LUKS adding one
<montjoie>
ssvb: cubieboard2
<ssvb>
you can probably try to reduce the DRAM clock speed in U-Boot just in case and see if that helps
<montjoie>
if I umount remove sun4i-ss and remount it, the bad block disappear
<montjoie>
what the fuck
<montjoie>
ssvb: I I disable irq the problem disappear so the RAM is goot for me
<ssvb>
cubieboard2 has a relatively high DRAM clock speed configured (480MHz)
<montjoie>
so something perhaps sent an interupt durring ciphering and boum
<ssvb>
OK, it's good to be so confident
<montjoie>
ssvb: which frequency do you recommend ?
<ssvb>
stressing DRAM simultaneously by the CPU and some hardware accelerator tends to expose reliability problems easier, that's how lima-memtester works
<montjoie>
400MHz ?
<ssvb>
yes, just drop it to 408 or even to 360, then see if this affects the bug reproducibility in any way
<montjoie>
ssvb: I will try it tonight
<montjoie>
I pray that its the issue
<tkaiser>
montjoie: The person who reported that first is also using Cubieboard2 :)
IgorPec has quit [Ping timeout: 268 seconds]
<montjoie>
checking with 408Mhz (I fail to wait for tonight)
<montjoie>
ssvb: how to know the current memory speed ?
<matthias_bgg>
apritzel, because I have to add the ATF to the uboot before calculating the checksum, right?
<apritzel>
yeah, it's a mess in the moment, sorry for that
<apritzel>
well, not really to uboot, but after u-boot
<apritzel>
the boot0 header has two pointers in it, one pointing at ATF, the other at the arisc firmware
<matthias_bgg>
apritzel, ah, ok, so the checksum in the u-boot header is independent of the ATF.
<matthias_bgg>
apritzel, I tried the u-boot from longsleep with your ATF and I booted to a u-boot command line. So I should be able to do this with your u-boot as well.
<matthias_bgg>
apritzel, let's see if I can help in any way to clean that up. maybe starting writing a small program for the checksum. what do you think?
<apritzel>
matthias_bgg: yes please, checksum generation is highly appreciated!
<matthias_bgg>
apritzel, ok, will give this a try
<apritzel>
I think somehow in longsleeps build process there is something in there
<apritzel>
if you could put your goggles on and go down there
<wens>
ssvb: i see you have some patches for the other chips, i'll wait until they're merged and use them as a base :)
<apritzel>
matthias_bgg: also we need separate U-Boot branches for FEL boot and boot0 at the moment
<apritzel>
FEL boot does not initialize ATF, so I call into it at the beginning of U-Boot
<apritzel>
that does not really work with boot0, which does that already
afaerber has joined #linux-sunxi
<apritzel>
matthias_bgg: so you need to revert the top-most commit for boot0 boot
<apritzel>
matthias_bgg: oh, also: the checksum in the boot0 header is about the whole thing, including the arisc and ATF bits
<matthias_bgg>
apritzel, well the topmost and the one adding libdram (d398e04)
<apritzel>
and what I saw is that just changing a single byte leads to a very similar checksum (adding 16 somewhere leads to 16 added to the checksum)
<apritzel>
libdram: of course
<matthias_bgg>
apritzel, ok, so I need to append the ATF first and then do the checksum. anyway, checksum calculation seems rather easy (found that in the SDK)
<matthias_bgg>
apritzel, I will start to write that little tool and then we can see how to go on
<apritzel>
matthias_bgg: don't tell that's easy, instead pretend it was horribly difficult ;-)
<apritzel>
btw: the pointers to ATF and arisc are at offset 0x500 of the boot0 header, you can adjust that as well
<matthias_bgg>
apritzel, what is the arisc though?
<apritzel>
the OpenRISC management core on the soc
<apritzel>
arisc in Allwinner speak
<apritzel>
it contains some code to drive the PMIC
<apritzel>
everyone seems to talk to that via a messaging interface to change PMIC settings
<alain_>
thanks, let me try it and get back to you
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
<montjoie>
working on removing PHY clk hack and proper MII/RGMII choice is my next task
joost_dtn has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
ricardocrudo has quit [Remote host closed the connection]
<alain_>
DTC arch/arm/boot/dts/sun8i-h3-orangepi-plus.dtb ERROR (phandle_references): Reference to non-existent node or label "emac_rgmii_pins" ERROR: Input tree has errors, aborting (use -f to force output) scripts/Makefile.lib:300: recipe for target 'arch/arm/boot/dts/sun8i-h3-orangepi-plus.dtb' failed make[1]: *** [arch/arm/boot/dts/sun8i-h3-orangepi-plus.dtb] Error 2
<lvrp16>
do you guys know where the orange pi one, pc, plus, plus 2 dtbs can be found?
<lvrp16>
i see plus in the mainline, but nothing for one, pc, and plus 2
<jelle>
pc is floating around on the mailing list or hans his sunxi-wip branch
<alain_>
I've applied 0001-ARM-dts-sun8i-add-sun8i-emac-ethernet-driver.patch and 0005-ethernet-add-sun8i-emac-driver.patch
reinforce has quit [Quit: Leaving.]
<lvrp16>
jelle: thanks
doppo has quit [Ping timeout: 268 seconds]
Andy-D has quit [Ping timeout: 268 seconds]
doppo has joined #linux-sunxi
<ssvb>
montjoie: not sure if this is yet another false lead - "Cortex-A7 erratum 823274: Load or store which fails condition code check might cause deadlock or data corruption"
<ssvb>
montjoie: the pre-requisite is a VFP divide or square root operation, executed no further than 58 instructions before some conditional load/store instructions in a certain pattern
lamer14585850198 has quit [Ping timeout: 240 seconds]
<montjoie>
alain_: rename it without rgmii_
<ssvb>
montjoie: how many instructions are needed for a context switch from some floating point userland process to this decryption loop in the kernel?
<montjoie>
a simple test could be to remove all readsl
<longsleep>
matthias_bgg: note that i did not clean up those tools, they are as found as in the BSP and really horrible :)
<ssvb>
montjoie: there is no workaround for this erratum, only fixes in updated revisions of Cortex-A7 processor
<ssvb>
montjoie: but it is expected to be extremely rare because the necessary conditions are rather difficult to reproduce
<montjoie>
I reproduce data corruption too frequently...
<ssvb>
well, most likely it is not this erratum, but something else
<alain_>
montjoie: ERROR (phandle_references): Reference to non-existent node or label "emac_pins"
Andy-D has joined #linux-sunxi
<longsleep>
Anyone has tried the mali-450 blob as relased by ARM with a mali-400? It it even worth a try?
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
mossroy has joined #linux-sunxi
cosm has joined #linux-sunxi
bwarff_ has joined #linux-sunxi
<montjoie>
alain_: emac_pins_a
<alain_>
thanks, trying now
akaizen has quit [Remote host closed the connection]
bwarff_ has quit [Ping timeout: 248 seconds]
<ssvb>
montjoie: how expensive is the use of spinlock_irqsave?
<ssvb>
montjoie: also I wonder if running something like this https://gist.github.com/ssvb/2c9995b43c97c5ec066a on both CPU cores together with the crypto test can lead to reproducing the bug easier?
<mripard_>
there would be a simple test to see if it might be the errata too, test it on an A10