<tllim>
Sorry on the delay of Pine A64+ 2GB board schematic release. I wil lmake the release on this weekend as my top priority task.
<tllim>
Appreciate on investigating into the GbE issue, I also like to know the answer.
<tllim>
Thanks tkaiser on the Armbian build release.
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jmcneill>
tllim: have you followed FreeBSD progress on Pine64?
<tllim>
I follow up on your progress on this IRC chat
<tllim>
but have no chance (in term of time0 to try out your FreeBSD build and i love to do so.
<jmcneill>
The A64 port is mostly on par with our other ports, with the exception of HDMI / FB (due to poor documentation from Allwinner)
<tllim>
Yes, libhdmi always a pain. I have chat with Allwinner on this topic
<jmcneill>
HDMI and DE2.0 register docs would be a huge help
<jmcneill>
I need to write the drivers from scratch after all, no GPL..
<tllim>
I have discussed with Allwinner on libhdmi topic, and ask them to help on this one.
<tllim>
I will email them again today and hopefully they respond back with positive answer.
<jmcneill>
Good luck!
<jmcneill>
(please ask about DE2.0 as well)
<tllim>
You can always email me at tllim@pine64.org if I didn't show up on IRC. I just read IRC history and decided to jump in today.
<jmcneill>
Same here, I am not often on this channel. jmcneill@freebsd.org if you can help the FreeBSD project in any way
<tllim>
I will ask DE 2.0 and email out to Allwinner engineering manager now.
<jmcneill>
Thanks!
<tllim>
will do, lets collaborate.
<tllim>
Thanks
popolon has quit [Quit: WeeChat 1.4]
<willmore>
tllim, Is there anything else you'd like me to look at on my board? I couldn't reproduce the problem.
kaspter has quit [Remote host closed the connection]
<tllim>
@willmore, you can explore on the tkasier finding. Until now, we only know that there are some boards don't work on GbE but we cannot pinpoint to the root cause. We know sthat this happens on both 1Gb and 2Gb. We also knows that this not be happen to partucular batch of board and seems random.
kaspter has joined #linux-sunxi
<willmore>
tllim, Seems I have a good board as I could not reproduce any issue--even at 4.5V. Has anyone tried a visual inspection? Maybe some part got populated incorrectly? But, you'd expect that to be batch dependent....
<tllim>
I have go thru with one KS backer who claims has 3 godo board and one issue board, he has taken a close up photo on the RTL8211 section, I cannot loacte any different between teh good and issue one. I have ask him to send teh issue board to me and I have not received yet.
<tllim>
In general, the components are popular by machine. If populate wrong value, then all same batch of boards are wrong value.
<willmore>
When/if you get it, I'd follow tkaiser's lead and check the voltages to the RTL chip.
<willmore>
Yeah, exactly, hard for the machine to put the wrong part in just *some* board. How much do you trust your board stuffers? I've heard some horror stories with parts being swept off the floor and put back on a reel....
<willmore>
The kinds of stories they tell young engineers to scare them at night. ;)
<tllim>
Tkaiser has the interesting point of view, I will ask the hardware engineer to recheck on the RTL8211 supply circuit.
<tllim>
No chance for random wrong value. The resistors, capacitors, inductors, and most active componets come in reel form, even parts that been pick up, there is hard to put back into reel. However, there is chance on miss staffing, but this is another story.
<tllim>
if hand soldering, then highly possible.
<willmore>
Understood.
<willmore>
If you think of something you would like tested, feel free to ask. I have a variable power supply and a four channel 100MHz 'scope, so I can look for things if I know what to look for.
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
<tllim>
Noted and thanks. Appreciaed on tkaiser finding and assistance.
tllim has quit [Quit: Page closed]
<willmore>
He's quite the resource.
ninolein has quit [Ping timeout: 250 seconds]
ninolein_ has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
tlwoerner has quit [Quit: Leaving]
uwe_ has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
uwe_ has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ganbold has joined #linux-sunxi
pg12_ has joined #linux-sunxi
pg12 has quit [Ping timeout: 276 seconds]
_mamalala_ has joined #linux-sunxi
_mamalala has quit [Ping timeout: 255 seconds]
imcsk8_ has joined #linux-sunxi
imcsk8 has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
Putti has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 244 seconds]
cnxsoft1 is now known as cnxsoft
kaspter has quit [Ping timeout: 264 seconds]
Putti has quit [Ping timeout: 244 seconds]
vagrantc has quit [Ping timeout: 244 seconds]
fire219 has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
scream has joined #linux-sunxi
scream has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 276 seconds]
jernej has joined #linux-sunxi
IgorPec has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
reinforce1 has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
yann has quit [Ping timeout: 276 seconds]
dearfibonacci has quit [Quit: Leaving]
dearfibonacci has joined #linux-sunxi
yann has joined #linux-sunxi
florianH has joined #linux-sunxi
wigyori has quit [Ping timeout: 276 seconds]
ricardocrudo has joined #linux-sunxi
tkaiser has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
apritzel has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<tkaiser>
jmcneill: Do you have a quick start guide how to build FreeBSD for Pine64? I'm interested in raidz stripe performance with 2 USB attached SSD so I need more than the 408 MHz.
cosm has quit [Remote host closed the connection]
<apritzel>
tkaiser: I can give you a one line U-Boot command to tune the CPU frequency ;-)
<tkaiser>
apritzel: great!
<tkaiser>
apritzel: Might be even better if I can add this to boot.cmd. At least 816Mhz would be cool. If that looks good I would maybe also try out 912Mhz and check reliability at 1100mV with Linpack like we did when defining dvfs settings for BSP kernel in March.
cosm has joined #linux-sunxi
imcsk8_ has quit [Ping timeout: 264 seconds]
<apritzel>
tkaiser: I checked the other day, indeed 408 MHz is the defaukt
<tkaiser>
apritzel: Yeah, 'confirmed' by sysbench (that's the only thing that is nice on sysbench since it does not depend on anything else like memory bandwidth you can calculate clockspeeds by sysbench scores :) )
imcsk8 has joined #linux-sunxi
<KotCzarny>
luckily mali doesnt work, or there will be glxgears 'benchmarks' he he
<apritzel>
tkaiser: can you give me the output of: md.l 0x1c20000 1
<tkaiser>
apritzel: Not yet, in an hour. Pine64 is in a location now where I can hardly attach a serial console
apritzel has quit [Read error: Connection reset by peer]
IgorPec has quit [Ping timeout: 265 seconds]
<tkaiser>
(and then I need to find Icenowy's USB patches and hope she already managed to bring the 'magic bit' in place to turn the OTG port into a full USB host port)
<MoeIcenowy>
tkaiser: Unfortunately, I will say no
<MoeIcenowy>
and I delayed the implementation because of some physical problem
apritzel has joined #linux-sunxi
<apritzel>
tkaiser: if I can rely on the manual ;-) it should be: mw.l 0x1c20000 0x80001010
<tkaiser>
MoeIcenowy: Too bad since I have 2 SSD here until mid of next week (then they're done since a customer needs them as boot array)
<apritzel>
which gives you 816 MHz
<tkaiser>
apritzel: I will try that out later and report back. Am I'm able to add this to boot.cmd also?
<apritzel>
as in: (24MHz*17*2)/(1*1)
<apritzel>
tkaiser: theoretically yes, but please check it beforehand ;-)
<MoeIcenowy>
my phy drivers are said to be applied by kishon
<apritzel>
Actually I will post an ATF patch which does this
<MoeIcenowy>
but I've never seen them in the tree
<montjoie>
apritzel could you try your big endian kernel with sun8i-emac ?
<apritzel>
tkaiser: if you want to experiment: stepping up in _48MHz_ steps is easy: just increase bits 12:8: 0x80001110, 0x80001210, ...
<apritzel>
montjoie: yeah, sorry, I didn't have time for that yet (because I have to find my big endian setup first again)
<apritzel>
montjoie: if you are blocked on this, just send out what you have and don't mention big endian ;-)
<apritzel>
if it is broken there, nobody will notice
<apritzel>
and so it's not a regression
<apritzel>
;-)
<apritzel>
as long as the modification still work in LE, of course
<montjoie>
apritzel: I am blocked by pm_runtime:)
<apritzel>
montjoie: I really get annoyed by everyone asking you to add featureX in your driver
<apritzel>
montjoie: if your driver works, it should be merged, we can make it fancy later
<apritzel>
montjoie: off-tree the testing exposure is much lower
<montjoie>
I think I will add the pm_runtime patch as RFC
<MoeIcenowy>
jmcneill: ping
<jmcneill>
hi
<MoeIcenowy>
where's your usb0 convert to ehci mode code?
<MoeIcenowy>
jmcneill: in linux phy-sun4i-usb.c it's named "REG_PHY_UNK_H3"
<MoeIcenowy>
I will change it according to your name...
<tkaiser>
apritzel: The u-boot stuff works. Of course I directly added it to boot.cmd and also using 912 MHz. Sysbench numbers indicate that the clockspeed works.
<apritzel>
tkaiser: nice one
<tkaiser>
apritzel: But no Ethernet any more. But this is not related to clockspeed, today I get always: [ 11.882393] sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY
<apritzel>
just waiting for your experiences now
<jmcneill>
MoeIcenowy: look two lines up.. :p
<tkaiser>
apritzel: Well, no Ethernet, no USB...
<apritzel>
tkaiser: can you at least run cpuburn?
<jmcneill>
same offset but i gave a different name because it only exists on the otg phy space
<apritzel>
tkaiser: I wonder if at least 816 MHz is still safe without further thermal checks
<MoeIcenowy>
jmcneill: in original linux phy driver
<jmcneill>
err not same offset
<tkaiser>
apritzel: Linpack would be more interesting. But I get 'no PHY' also with 816 MHz. Now trying 408 MHz again.
<jmcneill>
i need to wake up
<MoeIcenowy>
there's two UNKs one is PHY_UNK_H3 and another is PMU_UNK_H3
<MoeIcenowy>
PMU_UNK_H3 has renamed by me to PMU_UNK1
<MoeIcenowy>
and PHY_UNK_H3 can now be named PHY_OTG_CFG
<jmcneill>
ah
<jmcneill>
i think i made that name up
<jmcneill>
or maybe just the bitfield name
<tkaiser>
apritzel: 'execution time (avg/stddev): 9.1164/0.00' (that's 408 MHz) but also '[ 14.341761] sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY'
<tkaiser>
apritzel: Will now pick the 5.2V PSU and try it powering through Micro USB again
<apritzel>
tkaiser: yeah, we also had "Could not attach to PHY" when the DCDC1 power switch wasn't enabled
<tkaiser>
apritzel: Back in the game: 5.2V on the Micro USB connector and I have the PHY back: http://sprunge.us/bZVL (sent from the device)
<apritzel>
tkaiser: did you power it via Euler before?
popolon has joined #linux-sunxi
<tkaiser>
apritzel: Yes, with 2 cable pairs using pings 2, 4, 6 and 9. But this PSU provides only ~5.0V
<apritzel>
so this PHY powering is really sensitive ...
<tkaiser>
apritzel: Which is something I don't understand since PMIC should provide a stable voltage independent from input voltage. But the tests show the opposite and input voltage matters.
<apritzel>
tkaiser: indeed, especially as DCDC1 is the most powerful regulator
<tkaiser>
apritzel: I looked for a shop near the main station yesterday to buy a better PSU too. But 'Computer-Strich' as known before turned into Shisha Bars, Falafel Boutiques and Junk Food crap (subway). All the hardware shops are gone, seems everyone orders from Aliexpress in the meantime.
Putti has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<tkaiser>
montjoie: I had some hope GbE throughput would increase with higher CPU clockspeeds. But it's still 470 Mbits/sec regardless whether I clock with 408 or 854 MHz in TX direction. In the other direction I can not test since I only have a board here now that shows the GbE issue
<apritzel>
tkaiser: Computer-Strich: LOL
<MoeIcenowy>
jmcneill: you are much better than me on reading BSP
<jmcneill>
i've been through it many times, it never gets easier..
<apritzel>
jmcneill: so you are the "BSP whisperer", then ;-)
<jmcneill>
i've been called worse
<apritzel>
tkaiser: I guess you are still running with 200 MHz AHB2 ...
<apritzel>
tkaiser: short meeting, will tell you more runes in a minute
<tkaiser>
apritzel: Sure, whatever AHB2 might be ;)
<jmcneill>
AHB2 is the bottleneck for emac :)
<jmcneill>
it is the bus that emac lives on, defaults to a clock parent of AHB1 (which is 200MHz)
<MoeIcenowy>
mripard: will you soon rework A64 sunxi-ng and merge it?
<apritzel>
tkaiser: it's the clock for EMAC and USB
<jmcneill>
you can change it to PLL_PERIPH/2 which gives you 300MHz
<tkaiser>
jmcneill: I can't change it since I don't know what you guys are talking about :)
<tkaiser>
I need simply instructions at NOOB level then I can change stuff like that :) But only after lunch...
<apritzel>
jmcneill: yeah, I changed that in ATF already
<apritzel>
tkaiser: just a sec ...
<apritzel>
tkaiser: mw.l 0x1c2005c 1
<jmcneill>
apritzel: I still need to try your ATF branch.. I am concerned about synchronizing access to the RSB though
<apritzel>
jmcneill: should be no problem: ATF just initializes the RSB and sets up something initially
<apritzel>
jmcneill: unless called by the non-secure OS it doesn't touch RSB, at least not at the moment
<jmcneill>
What about a commit "sun50i: switch RSB and SRAM1 to be secure-only"
cnxsoft1 has joined #linux-sunxi
<apritzel>
jmcneill: nice, isn't it? Only that it doesn't work ;-)
<MoeIcenowy>
I pushed an untested branch to enable EHCI0 on Pine64
<jmcneill>
heh, well if you ever figure out why it doesn't work, that'll break my pmic driver :p
cnxsoft has quit [Ping timeout: 255 seconds]
cnxsoft1 is now known as cnxsoft
<apritzel>
jmcneill: either it's a some bit missing somewhere to enable this secure feature, or this doesn't work on the A64 at all ...
<apritzel>
jmcneill: I will drop this patch, at least enabling that unconditionally
<jmcneill>
tkaiser: if you want to test quickly, i can give you an older image and then you can just update the kernel+dtb
<jmcneill>
older will be like a week or two old, not a big deal
<jmcneill>
(but not new enough to have cpufreq changes)
<tkaiser>
jmncneill: Thanks, maybe too much efforts for now but I might give it a try. Switching from AHB1 to PLL... I get now 504 Mbits/sec with iperf3 compared to 470 Mbits/sec before :)
<jmcneill>
I'm told there's an issue with the efi bootloader at the moment, once that's sorted out I'll do an updated image
<tkaiser>
jmcneill: _If_ you could come up with a new image until next wednesday it would be great since I have 2 pretty fast SSD here to play with :)
premoboss has joined #linux-sunxi
<tkaiser>
MoeIcenowy: I tried your branch out but somehow messed things up and ended up without the SD card being recognized :) http://pastebin.com/hkxvmSqG
<topi`>
everyone is making noise about Apple event, but I'm waiting for that Solid-run event in October when they start shipping the Marvell 8040 board :)
IgorPec has joined #linux-sunxi
<topi`>
but first, I need to get some proper kernel support for the Xunlong camera modules... (gc2305)
pg12_ has quit [Ping timeout: 244 seconds]
pg12 has joined #linux-sunxi
<MoeIcenowy>
tkaiser: the branch doesn't support mmc at all
<tkaiser>
MoeIcenowy: A, that explains it :) Will try that out now.
<mripard>
MoeIcenowy: yes, tonight hopefully
<MoeIcenowy>
tkaiser: thanks
<MoeIcenowy>
mripard: also thanks... and I would say "finally"
<jmcneill>
tkaiser: did you find out if UASP was supported?
<tkaiser>
jmcneill: Nope, not even asked somebody.
paulk-collins has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
dearfibonacci has quit [Ping timeout: 244 seconds]
dearfibonacci has joined #linux-sunxi
<MoeIcenowy>
tkaiser: what's the result?
dearfibonacci has quit [Quit: Leaving]
dearfibonacci has joined #linux-sunxi
<tkaiser>
MoeIcenowy: Most probably that I'm doing something wrong. Simply exchanged kernel tree in Armbian's build system might not suffice. I'm currently looking through DT.
<tkaiser>
jelle: There is the hot M1 and the freaking hot NEO
<jelle>
lol
<jelle>
hmm nanopi-neo 1606
<jelle>
tkaiser: ^ is what it says on the paper
<tkaiser>
jelle: the NEO could really be interesting regarding DRAM since it's the first H3 device with single bank DRAM config.
<jelle>
aha let me commit the u-boot dts file and send upstream
Mr__Anderson has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
yann has joined #linux-sunxi
<jelle>
tkaiser: looks like it really has a heat issue
<jelle>
it just kernel paniced, let it cool down then booted again fine
<tkaiser>
jelle: Do you have FA's heatsink applied?
<jelle>
tkaiser: nope
<jelle>
I know I should :)
<tkaiser>
jelle: nope
<tkaiser>
jelle: One of the problems of this board seems to be U7, this is an LDO regulator next to DRAM. Simply touch if you're in need of pain. Overheats like hell
netlynx has quit [Quit: Ex-Chat]
<tkaiser>
And with their heatsink I fear it gets even worse. SoC stays cool but U7 overheats.
<tkaiser>
jelle: Also which DRAM clockspeed do you use?
<jelle>
hmm IR thermometer says soc 30 C ~, 46 C of what I guess is the LDO
<jelle>
tkaiser: let me see
<jelle>
tkaiser: ok where is that specified in mainline?
<tkaiser>
Vendor uses 432 MHz and that for a reason.
<tkaiser>
But decreasing the value by just 24 MHz saves a lot consumption and helps with temperatures. Sounds crazy but I tested it several times.
<jelle>
hmm wanna measure consumption
<tkaiser>
jelle: I used a Banana Pro and AXP209 and average values over 30 minutes.
<tkaiser>
IIRC 470mW difference in idle consumption when adjusting DRAM clockspeed between 132 MHz and 672 MHz
<tkaiser>
With all dual bank H3 boards it's just ~300mW. Also temperature differences are huge
<jelle>
let's measure it!
<tkaiser>
jelle: Anyway, when we made the settings for the NEO in Armbian we limit max cpufreq to 912 MHz (remaining at 1.1V) and use 408 MHz for DRAM.
<jelle>
tkaiser: ah ok
<tkaiser>
When testing with cpuburn-a7 without a fan blowing between heatsink and board while allowing more than 912 MHz the board always deadlocked