<megal0maniac_afk>
Quick question about the MAC on SoCs. Given that the physical implentation is handled by a PHYceiver, would it be theoretically possible to equip a SoC with an SFP port for different interfaces?
<megal0maniac_afk>
So you could switch between 1000base and fibre for example
FunkyPenguin has quit [Ping timeout: 240 seconds]
leviathanch2 has quit [Ping timeout: 265 seconds]
FunkyPenguin has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
<MadSpark>
megal0maniac_afk: afaik that is possible
<megal0maniac_afk>
Because from what I can gather, the SFP module deals with the same stuff as the phyceiver
<MadSpark>
i have seen app note connecting copper phy and fiber phy together without any mcu to convert 100Base-TX to 100Base-FX
<wens>
SFP seems to use SGMII, not supported I think
FreezingCold has quit [Ping timeout: 240 seconds]
<MadSpark>
might be easier to use phy + fiber optic module
<megal0maniac_afk>
I'm more interested in 1000base, but I thought SFP would be neat if it was compatible
bgal has quit [Ping timeout: 276 seconds]
nabblet has joined #linux-sunxi
<megal0maniac_afk>
Because then you could have a board with no interface, just an SFP port connected to the MAC and you can populate it if you need it
FreezingCold has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<MadSpark>
it is possible to convert rgmii to sgmii
FreezingCold has quit [Ping timeout: 276 seconds]
<Wizzup>
I'm confused about the SUNXI_SCALING_MIN option
<Wizzup>
It defaults to 60 but suggests that 408 Mhz is a much better value
<Wizzup>
And it also state that 408 Mhz is the ``last speed at the lowest voltage setting''
<Wizzup>
What does that ... mean?
<rm>
means the voltage used for running at 60...408 MHz is the same
<rm>
but go the next step after 408, and the voltage also steps up
<vector80>
IS there a clear explanation of those settings in the FEX? I mean, what is those LDO values, how to define voltages, what is the meaning of boot clock ?
<Wizzup>
rm: I see, that's not completely clear by "last"
<Wizzup>
thanks
hramrach has quit [Ping timeout: 272 seconds]
y0g1 has quit [Ping timeout: 240 seconds]
leviathanch2 has quit [Ping timeout: 240 seconds]
FreezingCold has joined #linux-sunxi
hramrach has joined #linux-sunxi
<ccaione>
vector80: IIRC you cannot define LDO voltages per se, with fex you can only define voltages for standby mode
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<libv>
what are the cubie guys up to these days btw?
<libv>
does anyone know what hw they are working on, or if they are working on new boards at all?
<mripard>
libv: some charbax video from yesterday hinted that they were working on the A80
<libv>
:(
<libv>
allwinner! get us mali hw!
<vector80>
ccaione: Thank you very much. I am wondering this one for example: dcdc2_vol = 1400 ?????????? What is this mean ?
leviathanch2 has joined #linux-sunxi
<ccaione>
vector80: iirc 1.4V when in standby for DCDC2
<rz2k>
libv: couple months ago benn send out an email about A80 board and etc to around 15 linux-sunxi guys, iirc you were in the list. maybe you'll find that email and bump it with questions? I guess its time to ask them.
<vector80>
ccaione: Thank you , very clear
<ccaione>
np
<vector80>
ccaione: What about those DDR settings? Such as dram_clk = 384
<ccaione>
for DDR stuff better asking ssvb
<vector80>
So, you mean, in the FEX, only one affecting performance is those DDR settings? any other one?
<libv>
rz2k: i was mostly wondering why they had been silent for several months :)
<libv>
but yeah, i did darkly remember them working on a80, sadly
byECHO has joined #linux-sunxi
<ccaione>
wow, already a patch on top of axp regulators
tomboy64 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 265 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<ssvb>
vector80: ddr settings in fex have no effect, everything is configured in u-boot
<ssvb>
vector80: at least they have no effect on the linux kernel, because it is too late to configure ddr there
<ssvb>
vector80: from what I heard, some tool is using these values from fex to inject them into the android bootloader, but I have no first hand experience with it
ojn has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
<vector80>
ssvb: thank you sooo much
<vector80>
So, in order to test better DDR speeds, I must try recompiling uboot
<vector80>
Is there a guide for the settings in the DDR ?
<ssvb>
jemk: what we are missing is likely a proper "DQS Gate Training" when initializing the dram controller
<ssvb>
jemk: and the rk30xx manual actually has a pretty detailed description of the dram controller initialization procedure with all the steps explained
<ssvb>
jemk: looks like the right thing would be to check the sunxi dram controller initialization code u-boot, and potentially even do a clean rewrite of it
y0g1 has joined #linux-sunxi
<lauri>
ssvb: It seems the HDMI troubles have dissappeared after I grounded the CT..
torindel has joined #linux-sunxi
<ssvb>
lauri: good :)
<lauri>
so the real question is where would you get a grounded adapter..
<lauri>
thanks for the memory overclocking hack though ;)
bbrezillon has quit [Ping timeout: 245 seconds]
leviathanch2 has quit [Ping timeout: 258 seconds]
<lauri>
well it seems it is nearly impossible to get a grounded charger..
* torindel
just got another two A20's
<torindel>
^^
FreezingCold has joined #linux-sunxi
<ssvb>
lauri: btw, have you tried to run the lima-memtester test program with the overclocked dram settings?
<lauri>
It's just I already use this box for everyday work :D
<ssvb>
so you can just download it, and run
<lauri>
great
<lauri>
it crashed
<lauri>
it rotated for like 200ms
<lauri>
and then boom
<lauri>
what does that mean?
<ssvb>
then it means that this level of dram overclocking is not stable for you
<lauri>
this talks directly to the mali chip right?
<lauri>
and the mali chip goes nuts with these clockings?
<ssvb>
it talks to the mali kernel driver and does not need anything else in the userland
<ssvb>
the mali chip can just stress dram really hard and expose problems
<lauri>
right
<ssvb>
you can reduce the dram clock speed or increase the dcdc3 voltage in the fex file
<lauri>
dcdc3 is already 1.3V
<lauri>
could I go higher?
<ssvb>
maybe, but that would be overvolting
geecko has quit [Ping timeout: 258 seconds]
<lauri>
let's fry some eggs & bacon!
<ssvb>
I have tried 1.35v myself, seems to work
<megal0maniac_afk>
I agree with ssvb. You are pretty reckless :)
<lauri>
I wish I had such toys when I was a kid! :P
<lauri>
So I gotta be kid now :)
<ssvb>
:)
<lauri>
But in all seriousness, I am torturing the machine as I use it. If it's stable for the workload then it's okay
<lauri>
1.35V crashed aswell
<ssvb>
do you have a ssh shell to the device? do you see the output on the console?
<ssvb>
btw, how big was the memory buffer you asked it to test?
<lauri>
emm
<ssvb>
something small like 100M is good enough
<lauri>
whatever the default is?
<lauri>
I did not specify any args
<ssvb>
oh, then it even did not try to start the memtester part, or it would have complained
<ssvb>
about the missing args
<lauri>
blerrrgh
<lauri>
so it didn't crash
<lauri>
(facepalm)
<lauri>
aaaaand I just had another HDMI disruption..
<megal0maniac_afk>
lauri: I seem to have those fairly regularly
<ssvb>
lauri: just run it from the terminal as "lima-memtester-arm-static 100M" and also watch the console output if you can
<lauri>
ssvb: yesyes now I got it
<lauri>
ssvb: I assume vsync is not supposed to be enabled right
<ssvb>
a ssh shell from a remote machine would be the best as you never lose the console output even if something fails
<lauri>
ssvb: yes-yes-yes! :P
<lauri>
so the grounding didn't do the trick :/
<ssvb>
right, there is no vsync, it runs at more than 300fps, precisely because we want to stress memory really hard :)
<ssvb>
lauri: btw, thanks for your feedback, I really need to make lima-memtester less confusing and more obvious to the users about what id does :-)
<ssvb>
lauri: I would have never imagined myself that the run without args would be interpreted as a "crash"
<lauri>
well for starters it could parse the command-line arguments *before* it draws anything on the screen :P
<ssvb>
ok, got it :)
<lauri>
alrighty
<torindel>
how complete is lima nowdays?
<lauri>
so 528MHZ @ 1.35V running now
<ssvb>
maybe the dram overclocking at 1.3v dcdc3 was actually stable after all
<torindel>
maybe i'll switch from proprietary drivers ^^
<ssvb>
lauri: you might want to go back to 1.3v
<lauri>
torindel: I am not expert of course but A10 was supported by lima driver
<lauri>
torindel: A20 is not completed yet I think
bgal has quit [Ping timeout: 250 seconds]
<ssvb>
lauri: unless you want to clock dram even higher :)
<lauri>
another HDMI glitch...
<lauri>
it seems load is triggering the disruption afterall
<ssvb>
yep, that's why stress test tools are good
<lauri>
so.. what else could I try with the HDMI problem..
<torindel>
lauri: and how complete it was for a10? got couple of thems around too
<ssvb>
they push your hardware to the limit and allow you to see if it can handle heavy load
<lauri>
torindel: I haven't had A10 :/
<lauri>
torindel: raspi and 3x A20 boards here
geecko has joined #linux-sunxi
<ssvb>
torindel: the only difference in a10 and a20 support for lima boils down to handling multiple pixel processors instead of one
<ssvb>
torindel: and I think that this is not a problem, libv can probably tell more
<lauri>
ssvb: 528MHz @ 1.3V running aswell
<ssvb>
torindel: about "switch from proprietary drivers", lima is perfectly good for a rotating cube using its custom api, but is not completely ready to offer a fully conformant OpenGL ES 2.0
<lauri>
ssvb: I can let it run over the night..
<ssvb>
lauri: that's a good idea
<ssvb>
lauri: also can you see the console output?
<lauri>
yeah I can let it run under screen or something
<ssvb>
lauri: because the errors may be reported there, while the cube is rotating seemingly fine
<lauri>
yep
<lauri>
anywho, if there are no issues with DRAM clocking, what else could cause the HDMI link disruption?
<ssvb>
actually I think that it would be nice to have something like a red flashing background in the case if errors are detected
<ssvb>
so that the users can see that there is a problem even without looking at the console output
<ssvb>
lauri: well, we currently believe that the CPU and Mali are starving the display controller and it sometimes can't scanout the framebuffer in time to send data over hdmi
<megal0maniac_afk>
Sounds reasonable
<megal0maniac_afk>
If only mali had its own memory
<lauri>
ssvb: should this be visible on VGA aswell?
<ssvb>
yes
* megal0maniac_afk
needs a block diagram
<lauri>
could you pump up VGA to FullHD?
<ssvb>
yes, you can have FullHD on VGA
<megal0maniac_afk>
It's one of the default fex options, isn't it?
<lauri>
It's not on fullhd by default IIRC
<ssvb>
and actually you can have FullHD on both VGA and HDMI simultaneously, but this is stealing even more of the memory bandwidth
<lauri>
I immideately switch to HDMI because of better quality
<megal0maniac_afk>
Not default, but it's one of the presets
Philippe_Fouquet has quit [Ping timeout: 245 seconds]
<ssvb>
lauri: the tuning of dram settings and clocking it higher might potentially help to mitigate the HDMI signal disruption issue, that's why we are working on it
<lauri>
ssvb: is there anything else I could try to work around the starvation problem
<ssvb>
lauri: as I said before, use 50MHz monitor refresh and overclock dram
<lauri>
It has been at 50Hz since you mentioned about it
nabblet has quit [Quit: leaving]
<lauri>
DRAM is at 528MHz
<ssvb>
yep, this definitely helps a it
<ssvb>
also normal workloads are usually much less intensive than lima-memtester, so it might be kinda alright to tolerate some very rare occasional hdmi glitches
<lauri>
once a day would be okay for me
<lauri>
but still.. it's not a real solution to the problem
<ssvb>
yep
<torindel>
lauri: about your hdmi problem first check power supply
<ssvb>
you can still move dram to 552MHz and check if the glitches become harder to reproduce
<torindel>
if it got enough amperage
<lauri>
torindel: I've got several power supplies here
<torindel>
i seen boards that on shitty power supplies worked but had wierd problem with peripherials like usb etc, gone when swaped power supply
<lauri>
torindel: I already know from my experience with raspi
<libv>
1) fel button, if at all possible, 2) clear picture of the serial/uart header, 3) ethernet phyceiver manufacturer and device
<megal0maniac_afk>
libv: Yes, but I'm not sure if the .fex files are different/more accurate
<megal0maniac_afk>
And I don't have the iteaduino plus I'm afraid
<megal0maniac_afk>
And the page in general is interesting. Providing libraries to abstract access to common IO
<libv>
anyway, i do not particularly care for that hw, i just want the wiki to be useful and to stop people from asking stupid questions or fucking about on the wiki
<megal0maniac_afk>
As long as the world contains people, and the people use the internet, I'm afraid you won't get that right :)
<libv>
i do get to slam stupid people more comprehensively.
<megal0maniac_afk>
You do. But hey! I'm asking less and less stupid questions every day :P
<megal0maniac_afk>
Actually I'm mostly just reading and picking stuff up
FDCX has joined #linux-sunxi
<megal0maniac_afk>
Those pictures are pretty poor...
<libv>
which pictures?
<megal0maniac_afk>
And the CPU is heatsunk so you can't see it (which isn't part of the design)