Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
forkit1 has quit [Read error: Connection reset by peer]
forkit has joined #linux-sunxi
Andy-D has quit [Ping timeout: 264 seconds]
Renard has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
Tartarus has quit [Ping timeout: 256 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Tartarus has joined #linux-sunxi
naobsd has joined #linux-sunxi
bsdfox has quit [Ping timeout: 250 seconds]
bsdfox_ is now known as bsdfox
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
naobsd has quit [Client Quit]
<wens> mripard: i'm really tempted to extend factors clk with custom recalc_rate callbacks, just to get rid of boiler plate code
<wens> for clocks such as sun6i's ahb1 clock
<wens> mturquette: hmm, nevermind
<wens> since the driver needs to read both the mux and divider values in recalc_rate, no need to call get_parent()
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
kaspter has quit [Ping timeout: 250 seconds]
kurain has joined #linux-sunxi
kaspter has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
vishnup has joined #linux-sunxi
arossdotme has quit [Ping timeout: 244 seconds]
bsdfox has quit [Ping timeout: 256 seconds]
arossdotme has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Ping timeout: 240 seconds]
firnsy has joined #linux-sunxi
TheSeven has quit [Ping timeout: 256 seconds]
p1u3sch1 has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
<firnsy> g'day all, i was having issues with the banana pi r1 (router board) with an attached sata not booting which lead me developing this patch http://fpaste.org/215669
<firnsy> in short port PB3 seems to be tied to the enable pin of the supply driving the sata power
<firnsy> i would like to clean up the patch for upstreaming but not sure how to progress, the patch is specific to the bpi r1 and i would think it would introduce /arch/arm/boot/dts/sun7i-a20-bananapi-r1.dts
<firnsy> any help in turning this into an upstreamable patch is greatly appreciated
<wens> different boards should have separate dts files, so yeah, introducing sun7i-a20-bananapi-r1.dts seems like a good idea
<firnsy> wens: ok, thanks
<firnsy> is there a specific maintainer's tree i should be targeting the patch against or do should i be using torvald's kernel tree?
<wens> you should use mripard's sunxi-next (on github) or sunxi/next (on git.kernel.org)
<wens> after he rebases the current stuff onto 4.1-rc1 of course
<firnsy> wens: thanks again
kaspter has quit [Ping timeout: 250 seconds]
leviathancn has quit [Ping timeout: 265 seconds]
naobsd has joined #linux-sunxi
p1u3sch1 has quit [Read error: Connection reset by peer]
p1u3sch1 has joined #linux-sunxi
bsdfox has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bsdfox has quit [Ping timeout: 256 seconds]
diego71 has quit [Ping timeout: 256 seconds]
diego71 has joined #linux-sunxi
khuey is now known as khuey|away
reinforce has joined #linux-sunxi
kelvan has quit [Remote host closed the connection]
kelvan has joined #linux-sunxi
bsdfox_ has quit [Ping timeout: 250 seconds]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
leviathancn has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 240 seconds]
sehraf has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 250 seconds]
sehraf has quit [Ping timeout: 272 seconds]
sehraf has joined #linux-sunxi
cajg has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
ganbold_ has joined #linux-sunxi
massi_ has joined #linux-sunxi
jackdaniel has quit [Remote host closed the connection]
domidumont has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
leviathancn has quit [Ping timeout: 272 seconds]
domidumont has joined #linux-sunxi
arete74 has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
prz has joined #linux-sunxi
mauro has joined #linux-sunxi
<vishnup> Hello,
leviathancn has joined #linux-sunxi
<vishnup> Is there any way we can put roots to RAM directly using FEL mode
<vishnup> ?
<mnemoc> use a kernel with embedded initramfs
<NiteHawk> http://linux-sunxi.org/FEL/USBBoot#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 also describes a method to achieve that
cubeast has joined #linux-sunxi
FDCX_ has joined #linux-sunxi
jemk has quit [Remote host closed the connection]
alexvf has joined #linux-sunxi
awe00 has joined #linux-sunxi
domidumont1 has joined #linux-sunxi
wickwire has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
alex___ has joined #linux-sunxi
<alex___> can someone explain how to change the name of my spidevice? I have the mainline 4.0 kernel with spi-sun4i and spidev driver on an cubietruck. The device name is /dev/spidev32766.0.
<mripard> alex___: what's wrong with that name?
<alex___> is that normal? I thought it should be named like spidev0.0
<mripard> it's not not normal :)
alexvf has quit [Ping timeout: 246 seconds]
<mripard> you need to add an alias to the spi controller you're using if you want to change the ID
<alex___> how do I do this?
Xaros has quit [Ping timeout: 264 seconds]
Xaros has joined #linux-sunxi
domidumont has joined #linux-sunxi
SQUelcher has quit [Ping timeout: 250 seconds]
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein1 has joined #linux-sunxi
<alex___> ok thanks i'll try
domidumont1 has quit [Ping timeout: 246 seconds]
alex___ has quit [Quit: Page closed]
SQUelcher has joined #linux-sunxi
fredy has quit [Excess Flood]
leviathancn2 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
leviathancn has quit [Ping timeout: 272 seconds]
fredy has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
leviathancn2 has quit [Ping timeout: 250 seconds]
cubeast has quit [Quit: Leaving]
jemk has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<wens> time to rebase everything
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<mripard> wens: yep
<mripard> did it this morning :)
<wens> should have the basic prcm driver ready in a few days
<wens> then might want to tackle smp on a80 :)
Xaros has quit [Remote host closed the connection]
Black_Horseman has joined #linux-sunxi
<mripard> yay
<wens> you could squash f1bf2b9b3d4b ARM: dts: sun9i: optimus: Switch to phy core regulator bindings for usb phys
<wens> into fa86885b6bc7 ARM: dts: sun9i: Enable USB support on A80 Optimus board
<wens> the separate conversion patch will actually confuse people, given the phy driver that was merged uses phy core regulator support
<wens> but i leave that to you
Andy-D has quit [Ping timeout: 256 seconds]
dev1990 has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 264 seconds]
<RSpliet> bbrezillion: ping!
<RSpliet> I wish to inquire about the status of MTD booting from U-Boot...
FDCX_ has quit [Ping timeout: 276 seconds]
simosx has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
kurain has quit [Ping timeout: 245 seconds]
leviathancn has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
simosx has quit [Ping timeout: 250 seconds]
alexvf has joined #linux-sunxi
leviathancn has quit [Ping timeout: 250 seconds]
nove has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
HeHoPMaJIeH has quit [Read error: Connection reset by peer]
Black_Horseman has quit [Ping timeout: 256 seconds]
domidumont has joined #linux-sunxi
leviathancn has joined #linux-sunxi
Renard has joined #linux-sunxi
leviathancn has quit [Ping timeout: 240 seconds]
diego_r has joined #linux-sunxi
Andy-D has joined #linux-sunxi
FDCX_ has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
arossdotme has quit [Ping timeout: 255 seconds]
arossdotme has joined #linux-sunxi
bsdfox has quit [Ping timeout: 256 seconds]
leviathancn has joined #linux-sunxi
FDCX_ has quit [Ping timeout: 240 seconds]
leviathancn has quit [Ping timeout: 250 seconds]
cajg has quit [Ping timeout: 244 seconds]
cajg has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 264 seconds]
Andy-D__ has joined #linux-sunxi
Andy-D_ has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
afaerber has joined #linux-sunxi
FR^2 has joined #linux-sunxi
arossdotme has quit [Read error: Connection reset by peer]
SQUelcher has quit [Ping timeout: 255 seconds]
SQUelcher has joined #linux-sunxi
khuey|away has quit [Remote host closed the connection]
khuey|away has joined #linux-sunxi
leviathancn has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
foudubassan has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
bsdfox_ has joined #linux-sunxi
sdschulze has joined #linux-sunxi
prz has quit [Ping timeout: 264 seconds]
mauro has quit [Remote host closed the connection]
arossdotme has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
khuey|away is now known as khuey
reinforce has joined #linux-sunxi
leviathancn has quit [Ping timeout: 255 seconds]
khuey is now known as khuey|away
kaspter has joined #linux-sunxi
arete74_ has quit [Read error: Connection reset by peer]
arete74_ has joined #linux-sunxi
cubeast has joined #linux-sunxi
Andy-D__ has quit [Ping timeout: 255 seconds]
diego_r has quit [Ping timeout: 276 seconds]
FR^2 has quit [Quit: Connection reset by peer]
khuey|away is now known as khuey
prz has joined #linux-sunxi
awe00 has quit [Ping timeout: 256 seconds]
massi_ has quit [Remote host closed the connection]
RzR has quit [Excess Flood]
RzR has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
bsdfox_ has quit [Ping timeout: 240 seconds]
ricardocrudo has quit [Ping timeout: 272 seconds]
bsdfox has quit [Ping timeout: 256 seconds]
bonbons has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
ricardocrudo has joined #linux-sunxi
dev1990 has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
afaerber has joined #linux-sunxi
awe00 has joined #linux-sunxi
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
physis has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
prz has quit [Ping timeout: 264 seconds]
Night-Shade has quit [Remote host closed the connection]
Andy-D__ has joined #linux-sunxi
FR^2 has joined #linux-sunxi
Night-Shade has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 250 seconds]
ricardocrudo has joined #linux-sunxi
physis has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 256 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 250 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 245 seconds]
<mripard> Turl: ping?
<mripard> do you remember where the rev A clock code was ?
Andy-D__ has quit [Ping timeout: 248 seconds]
<Turl> mripard: pong
<Turl> mripard: SoC detect set?
dack has joined #linux-sunxi
<Turl> mripard: I'm on a bus atm but I can look them up for you in 30m if you need them
Andy-D__ has joined #linux-sunxi
<mripard> no, I meant the thing that was showing which differences there were between the clocks in the rev A and rev B for pll2
<mripard> I can't find it anymore
<mripard> there's some slight change between sun4i/sun7i and sun5i about PLL2, I jsut want to see whether it's the same clock that it was in the rev A
<mripard> but I can definitely wait
<mripard> I was going to call it a day anyway :)
<Turl> mripard: ah, aw ccmu code? bunch of ifs on it
<Turl> I'll look for them in a bit
<mripard> yeah, I looked into that, but couldn't find it either
<mripard> anyway, not a big deal, I just wanted to know if you had that info at hand :)
reinforce has quit [Quit: Leaving.]
Andy-D__ has quit [Ping timeout: 252 seconds]
Andy-D__ has joined #linux-sunxi
physis has joined #linux-sunxi
froese has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 248 seconds]
simosx has joined #linux-sunxi
simosx has quit [Remote host closed the connection]
<sdschulze> Has anyone encountered the problem where U-Boot says "DRAM: 0 MiB [...] Please RESET the board"? It seems to occur across different boards.
<mripard> Turl: thanks
<mripard> so that's yet another thing :/
ssvb has joined #linux-sunxi
<Turl> mripard: what's the difference in 5/7i? I don't recall any
<Turl> sdschulze: sounds like a bad board or bad dram settings
<Turl> (or bad uboot, say, using sun4i one on sun7i or something)
FR^2 has quit [Quit: Leaving]
<sdschulze> Yes, but it's very strange. It works for for a few hours, then the problem occurs, and it takes weeks to recover.
<sdschulze> I thought it was maybe a cold solder joint, but Google says it occurs on different boards.
<Turl> it may be a bad solder on the dram, indeed
<ssvb> sdschulze: which boards?
<sdschulze> Myself, I'm using an Olinuxino A20-LIME2, but I also see reports about the Banana Pi and the CubieTruck. https://www.google.com/search?hl=en&q=u-boot+%22dram+0+mib%22+%22please+reset+the+board%22
<sdschulze> So I'm wondering if it might be a problem of the SoC.
<ssvb> sdschulze: all of the u-boot versions in these reports are very old
<ssvb> sdschulze: can you try the latest mainline u-boot?
<sdschulze> I can reproduce it with both uboot-sunxi and 2015.01.
<TheLinuxBug> sdschulze: hmm does this just cause the screen to go blank randomly?
<TheLinuxBug> sdschulze: wondering if this is what I was seeing the other day on my BPi
<sdschulze> TheLinuxBug: One time the screen turned green suddenly, actually. The other time it stopped sending an HDMI signal.
<TheLinuxBug> yeah I say it just stop sending HDMI signal
<TheLinuxBug> all the sudden when CPU load was around 1 (1 full core in use)
<sdschulze> The thing is: Software bugs aren't like: It works a dozen times in a row and then doesn't work 100 times in a row.
<TheLinuxBug> during compile or something it would be mid compile and hdmi would just quit
<sdschulze> This sounds like hardware.
<sdschulze> TheLinuxBug: Did the board work again when you rebooted?
<TheLinuxBug> yeah didn't have issues after reboot until I repeated same process
<TheLinuxBug> anytime CPU load would peak it seems it would drop HDMI, but to be honest I was positing this had something to do with the kernel I was using
<TheLinuxBug> so could still be that and unrelated
<sdschulze> That might be a thermal problem then.
<TheLinuxBug> k
<ssvb> sdschulze: if you are up to experimenting a bit, you may try to tweak CONFIG_DRAM_DQS_GATING_DELAY settings in the config file of your board in u-boot 2015.04
<sdschulze> Mine got "fixed" by sending it back to Olimex. It still worked when the sent it back, but failed quickly afterwards.
Andy-D__ has quit [Ping timeout: 256 seconds]
<sdschulze> *they
<mripard> Turl: the behaviour of pre and post dividers
<mripard> there's a +1 on the divider in the sun5
<ssvb> sdschulze: adding some debugging prints in the dram init code may help too
<sdschulze> Yes, some of the posts I find also mention DRAM timings.
<Turl> mripard: where are you getting this from?
<sdschulze> OK, I'll try that. I still don't see, though, why it first works for hours and then stops working for weeks if it's a timing issue.
<Turl> mripard: the sun4i and sun5i manuals I have say the same
<sdschulze> Something on the board must have "memory", but I don't see what.
<Turl> mripard: and in practice it worked audio wise :P
<ssvb> sdschulze: the dqs gating delay autodetection may be a little bit unreliable and not very deterministic
<ssvb> sdschulze: it depends at least on the temperature, maybe on some other factors too
<sdschulze> If the RAM was completely broken, U-Boot wouldn't be able to print anything, either, right?
<mripard> Turl: the user manuals curenntly on Allwinner's github
<ssvb> sdschulze: U-Boot starts from SRAM and initializes DRAM later
<sdschulze> Ah, I see.
<ssvb> sdschulze: this particular error message means that the DRAM failed to initialize
<ssvb> sdschulze: does the board boot successfully now? or is it in a failed state at the moment?
<sdschulze> Well, I don't really think it's temperature because the board still fails after hours. Because some spurious charge accumulating in some gate on the chip where it doesn't belong?
<sdschulze> It currently doesn't work.
<sdschulze> s/Because/Maybe/
dack has quit [Remote host closed the connection]
<sdschulze> And it failed before, but the flight to Bulgaria fixed it, apparently.
<sdschulze> Maybe it's air pressure. :D
<TheLinuxBug> LOL
<ssvb> sdschulze: the temperature is only a singe factor, we typically get different dqs gating delay settings autodetected, depending on whether it was a cold boot or a warm reboot :-)
<ssvb> sdschulze: they are still normally within a usable range, so the boards do not fail
<sdschulze> So my "spurious gate charge" hypothesis is not that weird?
<ssvb> sdschulze: I don't know what this "spurious gate charge" is supposed to mean :-)
<ssvb> I'm only saying that some of the DRAM settings get autodetected at runtime
<ssvb> if they somehow get autodetected very wrong, then your board may fail to boot
<sdschulze> Every 50th time or so, it seems to get past that stage, but didn't have a fully bootable system set up at that point, so I don't know if it would have worked.
<ssvb> does it fail again only on the next reboot?
<sdschulze> yes
<ssvb> or it can fail any time?
<sdschulze> Sorry, it failed 50 times, then semi-worked once and then failed again up to now.
<ssvb> if the dram is defective (bad solder or something), then we can't really do anything
<ssvb> but if there is some non-deterministic failure only at the dram init stage, then we can probably debug and fix/workaround it
<ssvb> sdschulze: anyway, can you try to compile U-Boot 2015.04?
<sdschulze> I've already contacted support and I hope they'll send me a replacement if the problem persists. But I want to see where it comes from and if it's a general bug.
<sdschulze> because I don't seem to be the only one experiencing it
interrobangd has joined #linux-sunxi
<sdschulze> Yes, I'm doing that.
<sdschulze> Vanilla first? Or with any specific changes?
<ssvb> yes
<ssvb> and then try again after adding CONFIG_DRAM_DQS_GATING_DELAY=0x05050505 line to the A20-LIME2 defconfig file
interrobangd has quit [Client Quit]
<ssvb> and you can also try 0x06060606
<ssvb> this overrides hardware autodetection and *might* work better
kevinsan has quit [Quit: ZNC - http://znc.in]
kevinsan has joined #linux-sunxi
<ssvb> sdschulze: adding debugging prints to this file might be really useful - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun4i.c
<sdschulze> Oh, neat, now it's working again...
<sdschulze> Well, kind of. The kernel gives weird errors.
<sdschulze> And now the error comes again.
<ssvb> working with vanilla u-boot or after tweaking something?
<sdschulze> vanilla 2015.01 right now (with legacy-hack enabled)
<sdschulze> Now I'll try 2015.14.
<sdschulze> *.04
<sdschulze> It works!
<sdschulze> (can't boot the kernel, though, because it's legacy)
<sdschulze> And now it stopped working after repowering a couple of times. Great.
<ssvb> it may start working again after cooling down a bit
<sdschulze> yes
<sdschulze> So I'll add CONFIG_DRAM_DQS_GATING_DELAY=0x05050505?
<ssvb> yes, that would be an interesting test
<ssvb> and if this does not boot, then also try 0x06060606
<sdschulze> It detects the DRAM but freezes after detecting the CPU.
<ssvb> 0x04040404 is unlikely to be good, but https://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/ mentions shorter tracks to DRAM
<ssvb> try to experiment with different CONFIG_DRAM_DQS_GATING_DELAY setups, one of them may be good
Andy-D__ has joined #linux-sunxi
<ssvb> if somebody with a working A20-LIME2 was here, we could just ask him to read the proper dqs gating delay settings from it
<sdschulze> How do you read it, in case mine starts working again?
<ssvb> via a10-meminfo tool from https://github.com/ssvb/a10-dram-tools
bonbons has quit [Quit: Leaving]
<sdschulze> 0x04040404, 0x05050505 and 0x06060606 all fail.
<sdschulze> So, higher number is more likely to work?
<sdschulze> But it *does* detect the RAM. It just doesn't go on after the CPU was detected.
juser123 has quit [Quit: ircII EPIC4-2.10.5 -- Are we there yet?]
<ssvb> the correct number is more likely to work, it should be related to the length of the tracks on the PCB
juser123 has joined #linux-sunxi
<ssvb> maybe try reducing the DRAM clock speed too
<juser123> afternoon. is thre an implementation of user space drivers for the A20 mali close to r5p0? I’ve got the kernel side built, but only see r3p1 on the sunxi git repo.
<ssvb> sdschulze: 480MHz may be too much - http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A20-OLinuXino-Lime2_defconfig
<sdschulze> What value do you suggest?
nove has quit [Quit: nove]
<ssvb> sdschulze: maybe around 384 or 408
<sdschulze> BTW, the current output is: http://pastebin.com/W3aaMJ8K
<ssvb> sdschulze: and try lower DRAM clock speed first without any adjustments for CONFIG_DRAM_DQS_GATING_DELAY
<sdschulze> I don't see any error there.
<sdschulze> It just doesn't boot.
naobsd has joined #linux-sunxi
<ssvb> sdschulze: yes, something is wrong
<sdschulze> And it's not because it can't boot the kernel, is it?
<ssvb> sdschulze: are you writing the u-boot-sunxi-with-spl.bin file to the sdcard when installing u-boot?
<sdschulze> yes
<ssvb> you should at least get the u-boot command prompt even without the kernel
sehraf has quit [Quit: www.miranda-fusion.de ... be part of it...]
<sdschulze> With 408, it stall right after "DRAM:".
physis has quit [Remote host closed the connection]
<sdschulze> same with 384
<ssvb> juser123: the userspace mali driver is a proprietary blob, only ARM can provide it (via Allwinner)
<ssvb> juser123: also are you sure that you got the kernel driver right?
<juser123> ssvb: yup, sure am. modinfo shows it as r5p1 which is what I pulled off the arm developer site. without the proprietary blob, it’s not much use to X11. but it works for the frame buffer
<ssvb> sdschulze: you can try to keep experimenting with different DRAM settings to see if anything consistently works better
<juser123> ssvb: i’m looking for sunxi’s release of arm’s later or latest blob for the user space
<juser123> heck, r3 is almost 2 years old
<sdschulze> I currently can't get any better than the pastebin link above.
<ssvb> juser123: do you get 3d acceleration in the frame buffer?
<juser123> ssvb: 2d via turbofb driver, but because of my mis match on the drm support it won’t render video, etc
<juser123> basic X11 apps work, etc.
cubeast has quit [Quit: Leaving]
<ssvb> juser123: driving the display is done without any use of mali hardware at all
<juser123> and its getting the hardware assist, no software rendering
<juser123> understood
<juser123> seperate core to move the memory image to the display
<juser123> the mali 400MP “just” renders to the memory
<ssvb> sdschulze: well, it could be a hopelessly defective hardware after all
<ssvb> juser123: mali is only ever used for 3d graphics, most likely you don't even have any applications which could benefit from it
<juser123> really, so i don’t need the mali.ko, mali_drm.ko, ump.ko modules to render video in X11 via the fbturbo driver?
<ssvb> "video"?
<ssvb> do you mean hardware accelerated movie playback?
<juser123> yes
<ssvb> for this you need the cedar kernel driver (already included by default) and https://github.com/linux-sunxi/libvdpau-sunxi
<sdschulze> ssvb: Yes, I will see what Olimex support says.
<juser123> so the result is I’m locked into the r3p1 driver chain
<ssvb> juser123: you don't need mali for video playback
<juser123> thought the cedar stuff depended on the mali.ko to be in place
<sdschulze> Maybe I will be able to read the gate delay when it has cooled down.
dev1990_ has joined #linux-sunxi
<ssvb> juser123: no, cedar is used for video decoding, mali is used for 3d graphics
<juser123> X11 hardware rendering requres what then? sorry for being so confused on it. been googling for days and still not 100% sure I’m getting it.
<ssvb> juser123: these are different accelerators, which are working independently from each other
<sdschulze> Considering that other users have reported the same problem, I hope they will give it some attention.
<ssvb> juser123: X11 desktop works best with software rendering on the CPU (accelerated via NEON SIMD instructions)
dev1990 has quit [Ping timeout: 272 seconds]
<juser123> crud.. now I’m totally confused. let me research it a moment and I’ll be back shortly.
<ssvb> juser123: as far as I know, there were no useful X11 hardware acceleration results on any ARM hardware
Netlynx has quit [Quit: Leaving]
<ssvb> juser123: moving pixels through the hardware accelerators makes the X11 graphics slow
<sdschulze> Just BTW, is it a know issue that mainline (Debian) 3.19 disables the 2nd CPU?
<ssvb> juser123: 1080p hardware accelerated video decoding can be done by the cedar hardware, but the usual 2d desktop stuff works best on the CPU
<ssvb> sdschulze: on which hardware?
<sdschulze> A20
<ssvb> the 3.19 kernel needs PSCI support in u-boot for SMP
<markvandenborre> -> debian server for the orange pi plus (H3)
<markvandenborre> are there any sources available to that one?
<ssvb> sdschulze: and PSCI is exactly the thing, which breaks legacy kernels
<markvandenborre> that's been released today
<sdschulze> Ah, so disabling the legacy hack should fix it?
<ssvb> yes
<sdschulze> The other issue was that my framebuffer was always 1024x768, but I can live with that.
<sdschulze> (simplefb)
<ssvb> is your board suddenly working correctly again?
<sdschulze> No, I tried that yesterday.
<markvandenborre> hm, maybe it was not interesting, or maybe noone noticed...
montjoie[home] has quit [Ping timeout: 250 seconds]
<sdschulze> I'm hopeful I'll be able to boot it after some cooldown, though.
<sdschulze> I got a lot further than with 2015.01.
<markvandenborre> I see that the orange pi people have released a debian server image for their Allwinner H3 based Orange pi plus
<markvandenborre> today
montjoie[home] has joined #linux-sunxi
<sdschulze> The sources for the operating systems mentioned are certainly available. The question is how much tweakage they need.
* markvandenborre would love a system like that
<markvandenborre> with some decent emmc on board, gbit and sata
<markvandenborre> would be an excellent fit four the book scanners I'm building
<markvandenborre> _if_ it can be coerced into running Debian reliably
<markvandenborre> sdschulze: what do you think? too early in the process?
<markvandenborre> I've toyed with some Chines A10 board a few years ago
<markvandenborre> but that was not ideal yet...
<markvandenborre> in terms of performance
<markvandenborre> (no nand, no ethernet, no sata, not enough usb ports)
<sdschulze> Well, things are usually more stable if you wait a bit of time.
<markvandenborre> what are my chances of being able to run this off nand?
<markvandenborre> any idea?
<sdschulze> You should check the manual for that.
<markvandenborre> because it seems a lot of the sunxi boards are only able to run linux from sd...
<markvandenborre> even after mainlining of uboot for them and device tree entries and whatnot
<markvandenborre> is that still the case?
<sdschulze> Mainlining takes a while.
<markvandenborre> yeah, I'm not scared of cross compiling if there is at least some basic docs
awe00 has quit [Ping timeout: 255 seconds]
<sdschulze> ssvb: Now it succeeds loading the second stage but still doesn't load the kernel.
<sdschulze> In the Olimex forum, someone actually recommends blowing the board with a hairdryer to fix cold solder joints.
<sdschulze> It has booted! :o
<ssvb> hairdryer helped?
<libv> sdschulze: there are tons of howtos to using an electric and temperature controlled oven
<libv> not very reliable or recommendable, but if you're lucky and hit reflow and nothing moves
<sdschulze> ssvb: No, it didn't.
<sdschulze> OK, it crashed again before I could install any of your tools.
physis has joined #linux-sunxi
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
<ssvb> sdschulze: this is not very likely to work, but you can also try to boot this sd card image - https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype
<ssvb> sdschulze: just one last thing to check is the cpu core voltage/frequency
<ssvb> sdschulze: at least some a10-lime boards had problems working at 1GHz / 1.4V reliably
<sdschulze> Do I need to run "make install" in a10-dram-tools, or can I run them from the source directory?
<ssvb> you can run them from the source directly
<sdschulze> "DRAM: 4 MiB" :o
<ssvb> hmm, that's something new
<ssvb> I guess, it's best to give up and just return the board to Olimex :-)
<sdschulze> "Card did not respond to voltage select!"
<sdschulze> I've already done that once, but I didn't have a serial adapter that time. I hope they believe me now that it's broken.
<ssvb> also maybe check the power supply
<ssvb> you can try to use a mini usb cable as an alternative source of power for the board
<sdschulze> I have tried different PSUs and different SD cards.
<ssvb> then it is strange that Olimex could not see any problem with the board
<sdschulze> If you leave it for a couple of weeks, it works well for a couple of hours.
<sdschulze> That's also what most people who receive the same error report.
<sdschulze> I don't think it's Olimex-exclusive. That's why I'm mentioning it here.
<libv> sdschulze: are _you_ seeing this with other devices?
<sdschulze> No, I don't own any other devices.
<ssvb> sdschulze: I see, I just thought that if the board can work fine indefinitely after it somehow manages to boot, then there might be something wrong happening specifically in the dram init
<ssvb> but if the board deadlocks or crashes after a few hours, then there is probably nothing that we can do
<sdschulze> Yes, it also crashes after booted up.
<sdschulze> It doesn't look like a software thing at all.
<libv> sdschulze: throw this on the ml, and add links to other people talking about this
<sdschulze> Which ML?
<sdschulze> My imagination is that there is a spurious capacitance somewhere on the board that gets charged slowly when running it and discharged very slowly when the board is turned off. When it's charged to a sufficient level, the board stops working. But I don't really know about chip manufacturing, so I'm not sure if that's a realistic hypothesis.
<sdschulze> Thanks, I will do that. I think I'll wait for the Olimex support response first, though.
iamfrankenstein has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 250 seconds]
<libv> you already sent it back, right?
<sdschulze> Once, yes.
<sdschulze> But they sent it back to me because it seemed to be working for them and I couldn't provide error messages.
<sdschulze> Now I can.
<sdschulze> They didn't leave it running for 10 hours, like I did.
<libv> email the ml anyway
<libv> more eyes looking on more data points would be a good thing here
<sdschulze> Yes. I hope Olimex will take it serious because they could be very helpful by sticking a couple of boards in parallel and check if they still work properly after ~10 hours.
<sdschulze> But apparently no-one who attends this channel so far has experienced it, so I'm not sure how rare it is.
bsdfox has joined #linux-sunxi
<libv> irc is great for direct conversation between a few people who are awake and around at the same time
<libv> ml is much better for your issue, and apparently the issue of many or several
naobsd has quit [Quit: naobsd]
<sdschulze> I will give myself and the board same rest and try again later. :)
<sdschulze> *some (I apparently do need rest)