<wens>
ssvb: they seem to be able to run at speeds lower than the configured rate, just slower
ricardocrudo has joined #linux-sunxi
hipboi has joined #linux-sunxi
hipboi has quit [Client Quit]
<ssvb>
wens: hmm, how does it work in practice? If somebody requests 50MHz in U-Boot here - http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c;h=e717c44216297fba3583098fad6cb20da8c58d98;hb=fa85e826c16b9ce1ad302a57e9c4b24db0d8b930#l87
<ssvb>
wens: but we configure 100MHz instead, then what happens?
<wens>
i guess the card can't keep up and you get a bunch of errors?
<ssvb>
wens: experiments with 4 micro sd cards show that they seem to be working seemingly fine
<lordlod>
I added the following to xorg.conf, now I have a rotated screen but it sits in the center vertically with the unrotated (800x480) resolution, rather than 480x800
<lordlod>
Option "Rotate" "CW"
<lordlod>
KotCzarny: Thanks I have that but it just does the terminal, doesn't seem to impact X
<KotCzarny>
does xrandr works?
<KotCzarny>
*work
<lordlod>
not to rotate
<lordlod>
and once I put the manual rotate line in xorg.conf it disables xrandr completely
paulk-collins has quit [Remote host closed the connection]
<ssvb>
wens: ^ could you probably have a look at it?
<ssvb>
as I said, I'm a bit puzzled why it was working in the first place, and would really like to try my old full sized slow (class 4) sd card which failed to work at 100 MHz in ODROID-X
<KotCzarny>
ssvb: alien interference?
<KotCzarny>
or just interference in general
<ssvb>
well, it would be great if somebody could maybe check the real mmc interface clock speed with an oscilloscope
<KotCzarny>
drat
<KotCzarny>
either my enclosure sucks or opipc fails with huge usb transfers
paulk-collins has joined #linux-sunxi
<lordlod>
argh, fixed my problem... after a number of hours. The program I was launching was hardcoded to 800x480, X was fine.
<KotCzarny>
:)
vishnup has quit [Quit: Connection closed for inactivity]
<wens>
ssvb: could you also dump the registers of mmc mod clock?
orly_owl has quit [Ping timeout: 260 seconds]
<ssvb>
wens: SDMMC0_CLK_REG or maybe SMHC_CLKDIV?
IgorPec has joined #linux-sunxi
premoboss has quit [Remote host closed the connection]
<ssvb>
wens: it would be probably much more efficient if you investigated all of this yourself (as you already have some experience with mmc)
<tkaiser>
Just out of stock and will be produced after end of Spring Festival
<KotCzarny>
i wonder how much more would opipc would cost with 2GB ram?
<ssvb>
wens: I just don't feel comfortable trying to fix a problem that I even can't reproduce, and I also don't have much experience with the mmc driver
<jemk>
ssvb: i measure 50MHz without your patch and 25MHz with patch
<ssvb>
testing your use case with a 4.x kernel would be also interesting
<KotCzarny>
i need hdmi, network, smp and power management at least
<KotCzarny>
is it already in mainline?
<ssvb>
not yet
<KotCzarny>
i can switch network with usb if its the blocker
<ssvb>
usb support is still also available as separate patches for the mainline kernel, but you can nevertheless test your usb hard drive and see if it works reliable or not
<KotCzarny>
simple test is just copying 4GB file from sd to usb(ssd)
hipboi has quit [Quit: This computer has gone to sleep]
apritzel has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
arossdotme-planb has joined #linux-sunxi
hipboi has joined #linux-sunxi
vishnu_ has quit [Quit: Leaving]
vishnup has joined #linux-sunxi
arossdotme has quit [Ping timeout: 264 seconds]
Ueno_Otoko_ has quit [Ping timeout: 265 seconds]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
codekipper has joined #linux-sunxi
hipboi has quit [Quit: This computer has gone to sleep]
<KotCzarny>
uh, oh, failed at 672, reducing
<KotCzarny>
how long shall it run?
engideavr has quit [Quit: Konversation terminated!]
<plaes>
until leds stop blinking
<plaes>
Orange Pi PC?
<KotCzarny>
well, if the test is stable, green will be blinking forever
<KotCzarny>
so.. till the end of the world?
<KotCzarny>
yeah, opipc
<KotCzarny>
just wondering what time it was setup to light the red one
<plaes>
~~20m
<KotCzarny>
k
<plaes>
at least I am not the only one with failing 672MHz :P
<KotCzarny>
:)
<KotCzarny>
this opipc is bought second hand
<KotCzarny>
dont know what owner was doing with it
<KotCzarny>
probably running at 1.5ghz stock
<KotCzarny>
i wonder if powersource voltage plays any role in eventual failing
vishnup has quit [Remote host closed the connection]
<plaes>
memtester was basically the first thing I ran on my device
vishnup has joined #linux-sunxi
<plaes>
could you add your SOC markings to the table too when you're finished testing
<KotCzarny>
will do
<KotCzarny>
btw. did you try redoing tests wuth heatsink?
<plaes>
nope
vishnup has quit [Remote host closed the connection]
<ssvb>
KotCzarny: a heatsink is unlikely to be relevant, DRAM chips in Orange Pi PC are DDR3L-1600, but downclocked to DDR3L-1333 speed and operating at reduced voltage 1.35V
<KotCzarny>
ssvb: how come they fail then?
<KotCzarny>
bad board design?
<ssvb>
the DRAM controller in H3 is rated as DDR3-1333, and also PCB tracks routing does matter
<KotCzarny>
bad board design then
<ssvb>
not necessarily, there are also board specific impedance and delay settings which affect reliability
<KotCzarny>
isn't that part of board design?
<ssvb>
these settings are configured in software
<KotCzarny>
uhum
<ssvb>
of course, the hardware design needs to match these software settings to get best results
<ssvb>
if they are mismatched, then you need to update either the hardware or the software
<KotCzarny>
green blinkin game still going strong
<KotCzarny>
quite probable 648 is stable on this board
<ssvb>
well, we can't be completely sure (what if it fails after running 1 hour non-stop? or one day? or one week?)
<KotCzarny>
yes, i will do longer tests when i finish configuring this board and move to bpi-m1
<ssvb>
that's why it is reasonable to reduce the DRAM clock speed by at least one more step to have some safety margin
<ssvb>
which looks like 624 MHz may be a good choice for you
<KotCzarny>
at 672 it was failing quick 1-2 minutes
apritzel has joined #linux-sunxi
<KotCzarny>
ssvb: does mem speed influence usb reliability?
<ssvb>
obviously if you have random memory corruption, then you can have all kind of reliability problems
<KotCzarny>
hmm, 30 minutes of testing
<KotCzarny>
and gotta go, i'll add the result with remarks
<ssvb>
thanks!
fredy has quit [Excess Flood]
<ssvb>
GeneralS1upid: ^ didn't you have some reliability problems on your Orange Pi PC too, but never had a chance to test it with lima-memtester?
fredy has joined #linux-sunxi
<KotCzarny>
added
reinforce has joined #linux-sunxi
<KotCzarny>
red led on
<KotCzarny>
still blinking
<KotCzarny>
k, powering off and i'll add markings
premoboss has joined #linux-sunxi
<KotCzarny>
btw. who said opi doesnt work on only usb-otg?
<KotCzarny>
i've just disconnected power (leaving otg cable plugged) and it's still blinking
<KotCzarny>
my hdmi went black tho, probably not enough power from laptop
<KotCzarny>
added
domidumont has quit [Read error: Connection reset by peer]
<ssvb>
KotCzarny: which FEX file are you using for your loboris kernel?
<ssvb>
KotCzarny: we need to reduce the DRAM clock frequency in it to 624 MHz
<sarietta>
hey all. i'm having an issue re-assigning UART1 from pins PG03/PG04 to PE10/PE11. i have updated my script.fex and removed all console usage lines from boot.cmd and inittab. the specific issue i'm seeing is that while the TX line of UART1 does indeed correctly get remapped to PE10, the RX line of UART1 does not get remapped to PE11.
<sarietta>
i have verified that i am sending data over the RX line via a scope, so the issue must be happening either at the OS level or the hardware level
<sarietta>
the specific hardware i'm using is an A13
<sarietta>
wondering if anyone has seen this issue before and/or knows what the problem/solution might be
premoboss has joined #linux-sunxi
BroderTuck has quit [Quit: Page closed]
afaerber has quit [Quit: Ex-Chat]
sunxi_fan1 has joined #linux-sunxi
Netlynx has joined #linux-sunxi
sarietta_ has joined #linux-sunxi
sarietta has quit [Read error: Connection reset by peer]
premoboss has quit [Ping timeout: 245 seconds]
iamfrankenstein1 has quit [Ping timeout: 245 seconds]
<apritzel>
sarietta_: are you sure that there is nothing else resetting the muxer? Can you verify the mux setting?
premoboss has joined #linux-sunxi
yann|work has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<sarietta>
yes. i have grepped the script.fex file to ensure no other entries reference PE11
<sarietta>
in addition. under my current configuration, if i connect a serial cable to PG04 for the TX line and PE10 for the RX line, UART1 behaves as expected. if i then switch the TX line of the cable to PE11, the A13 stops being able to receive data
<sarietta>
so it's as if something is preventing me from switching RX from PG04 to PE11
<Turl>
sarietta: is csi0 disabled?
<Turl>
can you paste your fex somewhere?
<GeneralS1upid>
ssvb: yes, but it turns out that it was the cuurrent