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
<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
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.
<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
<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.
<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?
<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>
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. :)