rexxster has quit [Remote host closed the connection]
rexxster has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 265 seconds]
hipboi has joined #linux-sunxi
chlorine has joined #linux-sunxi
junnie__ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
lurchi__ is now known as lurchi_
junnie__ has quit [Ping timeout: 240 seconds]
junnie__ has joined #linux-sunxi
rant has joined #linux-sunxi
<rant>
If anyone can tell me what is holding up HDMI on h3/opilite mainline or if there is something maybe I could do to help, I'd appreciate it..
<rant>
I'd really like to get on a mainline kernel on my opilite and I use HDMI display for it.. and it just baffles me what the holdup could be when it works on this old kernel so its not like we don't know how to make it work..
<rant>
my only guess could be that its using something that taints the kernel in some way and there is further reverse engineering required to get it in the mainline
lrusak has quit [Remote host closed the connection]
lrusak has joined #linux-sunxi
jtf has quit [Ping timeout: 240 seconds]
jtf has joined #linux-sunxi
afaerber has quit [Ping timeout: 255 seconds]
nots has quit [Quit: Page closed]
<lurchi_>
the DE2 (display engine) in H3 is completely undocumented, and there is no source code available from AW
afaerber has joined #linux-sunxi
junnie__ has quit [Ping timeout: 240 seconds]
<rant>
lurchi_: yeah, thats the case with most of this hardware.. but its puzzling that I'm using that old 3.4.113-sun8i now and the HDMI works fine.. if we already got it working.. do you mean to say the driver in that kernel we already have is entirely binary?
<lurchi_>
binary code drop
<rant>
ah.. well that would make sense then.. I was under the impression someon had already got it working I didnt know it was just a binary blob that had it working in the old kernel
paulk-gagarine has quit [Ping timeout: 276 seconds]
<rant>
I was just over there reading that stuff I didnt see mention of more than Simple FB
<rant>
oohh..it says DE2.. balah blah blah as well
<rant>
problem was I didnt know until you said it what DE2 was referring to :P
<rant>
I'm trying to use this thing for a really light desktop purposes.. nothing fancy.. but its running like crap on armbian/jessie right now I was waiting for that HDMI support so I could move on to a modern kernel and maybe ditch armbian support altogether and just use pure debian
<rant>
I'm actually not sure what is causing me problems currently.. I just know the system lags severly at times even running a simple thing like chmod/chown or df or something it may seem to lockup for sometimes minutes
<rant>
none of my resource monitors are showing me anything that'd explain it
<t3st3r>
rant> maybe your "disk" is just slow?
<t3st3r>
I mean block storage with OS installed, slow system device hurts
TheSeven has joined #linux-sunxi
<t3st3r>
but its wild guess, fast SD card is a must for anyhow sane experiense, like UHS-I or so
<rant>
I thought that too because I was only using the crappy sd for booting, I was using a USB HDD for the os, and I had an encrypted /home but I tried both switching to a 128gb thumbdrive and trying using a user without an encrypted home (unmounting all cryptfs) and it was still sluggish
<rant>
and iostat wasnt making it obvious that this was the issue
xyntrix has quit [Quit: Leaving]
TheSeven has quit [Ping timeout: 260 seconds]
<t3st3r>
well, I had similar lags with slow SD, that's why I've had this idea. Could be smth else
<rant>
might be.. but I'd think being that I'm not actually using the SD for much othe rthan booting I doubt the SD speed is the issue.. thats not to say the USB bus isnt slow and the devices I'm using arent slow as well
lurchi__ has joined #linux-sunxi
<rant>
and undoubtedly when using luks thats gonna hurt on an SoC .. one without full range of hw crypto support no less
<rant>
but I'd think I'd see that overhead using a process manager like htop or iostat or such.. I should see that lag somewhere
JohnDoe_71Rus has joined #linux-sunxi
<rant>
but I'm seeing plenty of mem available, cpu minimally in use..etc.. and yet its locking up quite frequently :P
<rant>
makes me think its something else.. in fact my best guess based on what I know as a computer tech is if I had a system with weird issues I couldnt explain I'd blame the power supply
<rant>
which I've been running this thing off a 2a samsung wall wart.. which I doubt is really sufficient as it was meant for a fairly short-term constant draw.. not the kinds of long-term dynamic draw this SBC probably requires
lurchi_ has quit [Ping timeout: 256 seconds]
TheSeven has joined #linux-sunxi
TheSeven has quit [Ping timeout: 255 seconds]
<icenowy[m]>
jernej: I followed set_pll_ahb_for_secure
<rant>
unfortunaely I dont have any other sort of power swupply nor would I know where to get one that would be antything more than what I got
TheSeven has joined #linux-sunxi
<icenowy[m]>
but I now doubt whether mbus is properly set
<icenowy[m]>
seems not
<jernej>
rant: t3st3r: I hope H3 HDMI mainline driver will be merged in 4.17. I prepared it, but before that few other patches needs to be merged first.
<jernej>
icenowy[m]: What about set_circuits_analog()?
<jernej>
did you tried that? I'm not sure what it actually do.
chlorine has joined #linux-sunxi
<jernej>
rant: t3st3r: AW actually provided DE2 documentation. You can find it on wiki
rant has quit [Ping timeout: 255 seconds]
hanni76 has joined #linux-sunxi
<t3st3r>
seems he haven't seen it due to ping timeout :(
chlorine has quit [Ping timeout: 240 seconds]
<jernej>
icenowyn[m]: What do you think is wrong in mbus code? I checked values against disassembly and they seem identical.
junnie__ has joined #linux-sunxi
<icenowy[m]>
jernej: mbus is upclocked in clock_spl.c
reinforce has joined #linux-sunxi
<icenowy[m]>
the value set in libdram/dram_sun50i_h6.c is only a failsafe clock at 24MHz
<jernej>
aha, this shouldn't be hard to test then
<icenowy[m]>
which just enables the access to the DRAM
IgorPec has joined #linux-sunxi
<jernej>
icenowy[m]: Did you see commit on my github where I reworked setting DRAM delays?
dddddd has quit [Remote host closed the connection]
f11f12 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<smaeul>
any reason why u-boot SPL would sometimes detect more RAM than is present? this is on OPi Zero+ H5, and after rebooting I got "DRAM: 2048 MiB" from SPL. It did it again after unplugging power for a few seconds, but the third try it worked fine: http://ix.io/Han
<KotCzarny>
floating electrons?
<icenowy[m]>
smaeul: could you add some debug code in sunxi_dram_init at dram_sunxi_dw.c?
<icenowy[m]>
print the content of struct dram_para
<icenowy[m]>
mbus upclock makes usb3 works so faster
<icenowy[m]>
get 320MB/s R and 75MB/s W on a Samsung SSD 850 EVO 250G
<icenowy[m]>
(sequence
<t3st3r>
wow!
<t3st3r>
so it was underclocked bus?
anarsoul has quit [Remote host closed the connection]
hardfalcon has quit [Ping timeout: 248 seconds]
<t3st3r>
seems NAS fans could finally have what they want oO
anarsoul has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
<icenowy[m]>
yes it's underclocked mbus
<icenowy[m]>
(mbus should mean memory bus)
yann has quit [Ping timeout: 240 seconds]
sr-digitronic has joined #linux-sunxi
clemens3 has joined #linux-sunxi
sr-digitronic is now known as basxto_
xerpi has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
xerpi has quit [Read error: Connection reset by peer]
xerpi has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<icenowy[m]>
smaeul: sequence?
<smaeul>
same as struct
<icenowy[m]>
is there any data for 2048?
<smaeul>
I've only seen it do that a couple of times (and it always does 512M when resetting from within u-boot, so I have to reboot from Linux to test)
<icenowy[m]>
and have you tried downclock DRAM?
<smaeul>
no, what do I need to change? u-boot .config?
msimpson has joined #linux-sunxi
<icenowy[m]>
yes
<icenowy[m]>
CONFIG_DRAM_CLK
<icenowy[m]>
P.S. your thing seems really so strange
<smaeul>
huh, CONFIG_DRAM_CLK=312
<smaeul>
looks like there's a lot of CONFIG_SUN50I_H5 missing from arch/arm/mach-sunxi/Kconfig
<BenG83_>
GbE was looking ok yesterday even before fixes
<BenG83_>
930Mbit/s and 720Mbit/s before touching any rx/tx delays
fkluknav has quit [Ping timeout: 265 seconds]
tkaiser has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
tllim has joined #linux-sunxi
tl_lim has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
tllim has quit [Ping timeout: 256 seconds]
fkluknav has joined #linux-sunxi
<BroderTuck>
Hi all. Anyone willing to take a look at my bootlog https://pastebin.ubuntu.com/p/ysdTsX4jm9/ and tell me if it's 1) uboot config, 2) uboot dts, 3) linux config, 4) kernel dts, or a uboot/kernel source issue that prevents my usb ports working properly? 4.10 worked fine, at least the non-otg port. (HYH-TBH3 using orangepi_pc defconfig/dts)
xyntrix has quit [Ping timeout: 268 seconds]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
nvz_ has joined #linux-sunxi
<icenowy[m]>
BenG83: I think I set some tx/rx delay
<tkaiser>
Still, a comparison with a BSP based OS image would be interesting :)
<BenG83_>
those in the log
<BenG83_>
yeah I will see if that OPi image boots
<BenG83_>
I managed to build all the parts of the BSP two weeks ago but didnt try to make an image
<BenG83_>
missing the fex file for PineH64 too atm
<tkaiser>
BenG83_: Wrt read performance I would believe iozone is currently CPU bottlenecked with just 912 MHz. Once this limitation is gone we should see 380-390 MB/s
<BenG83_>
possible
<jernej>
so, how good are those results?
<jernej>
I mean read performance, since write should be improved somehow
<BenG83_>
390MB is around the theoretical maximum
<BenG83_>
so that looks ok
<tkaiser>
jernej: Read performance is great, the benchmark tool itself is most probably here the bottleneck already
<BenG83_>
it is the same IP as in RK3328 so I would expect that
<jernej>
what about pcie? should it offer even better performance?
<tkaiser>
BenG83_: Which is something we should keep in mind when testing with iperf3 too. Also with just 912 MHz prone to be bottlenecked by the benchmark and not reality
<buZz>
there are allwinner socs with PCIe now?
<tkaiser>
If you watch with htop you'll see the core iperf3 is running on most probably at 100%
<BenG83_>
H6 has one lane
<buZz>
omg
<BenG83_>
making the glue layer for PCIe is outside of my skill range :P
<BenG83_>
I have read through the BSP PCIe driver code a bit
<jernej>
well, you just look at the code of other glue drivers and BSP driver and make something up :)
f0xx has joined #linux-sunxi
<BenG83_>
lol
basxto_ has quit [Remote host closed the connection]
scream has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
<jernej>
icenowy[m]: Did you see that BenG83_ reported problems with RAM size detection for 4GB (actually 3GB) variant
xerpi has quit [Quit: Leaving]
f0xx has quit [Ping timeout: 268 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
<icenowy[m]>
jernej: I have seen -- it works for me