avph has quit [Read error: Connection reset by peer]
avph_ is now known as avph
fl_0 has quit [Ping timeout: 240 seconds]
MACscr has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<MACscr>
I have a pcDuino3b (A20) running the latest armbian (so much better than the linksprite images). Anyway, im trying out an ssd connected to the sata and the max write speed i can get is 35BM/s. Makes me think its going through usb 2.0 bus, but i thought that wasnt the case with the A20's
fl_0 has joined #linux-sunxi
<MACscr>
im getting way better iops though than i was using the same disk on a usb 3.0 cable connected to a usb 2.0 port
<MACscr>
the sata wiki page looks good though, so im going to test some of those ideas out
flok420 has joined #linux-sunxi
flok420 has quit [Ping timeout: 245 seconds]
lamer14534031262 has quit [Ping timeout: 272 seconds]
sigjuice has quit [Ping timeout: 265 seconds]
sigjuice has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
khuey is now known as khuey|away
Ueno_Otoko has joined #linux-sunxi
flok420 has joined #linux-sunxi
flok420 has quit [Ping timeout: 265 seconds]
Ueno_Otoko has quit [Ping timeout: 272 seconds]
apritzel has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
solarnetone has quit [Ping timeout: 265 seconds]
solarnetone has joined #linux-sunxi
<wens>
ssvb: i believe i mentioned an alternative in that mail?
<wens>
on the side, the pin drive strength should be set in the driver to match the usage
cnxsoft has quit [Read error: Connection reset by peer]
<wens>
i believe dw_mmc (or some other controller) does this using pinctrl API
cnxsoft has joined #linux-sunxi
<ssvb>
wens: the "mmc-ddr-1_8v" DT capability flag at the dtsi as an alternative?
<wens>
yes
<wens>
ssvb: in my series, ddr-1_8v is declared in the driver
<wens>
instead we could declare it in the dtsi or dts
<wens>
if it's not declared, mmc won't try ddr modes
<ssvb>
yes, putting it into DT looks like a reasonable solution to me
<ssvb>
if DT describes the hardware, then we need a way to describe this 8 bit DDR mode capability
<wens>
i'm still waiting for others to comment on it
<ssvb>
are 1.8V voltage and 8 bit DDR mode always used together?
<wens>
unfortunately 8-bit is another property
<wens>
"mmc-ddr-1_8v" means the controller can run eMMC DDR at either 1.8v or 3.3v signalling
<wens>
the voltage seems to be a hardware feature, depending on the chip you have, it either runs at 1.8 or 3.3
<ssvb>
let's rephrase the question as "are 1.8V voltage and DDR mode always used together?"
ninolein_ has quit [Ping timeout: 240 seconds]
<wens>
again, the property is misleading: it means the controller can do MMC HS-DDR
<wens>
not that it supports 1.8v
<ssvb>
does it need a misleading name then?
ninolein has joined #linux-sunxi
<wens>
in some other series there's talk about adding mmc-ddr-3_3v
<wens>
but that is what the core bindings are for now
<ssvb>
ok, I see that it is this way because of historical reasons
<wens>
for eMMC we would always use 8bit (bus-width = <8> in the DT), since it is supported (eMMC on PC pins has 8 data pins) and is faster
<wens>
however when those were added, DDR support wasn't there, so the pin drive strengths might be wrong as well
<wens>
so using "mmc-ddr-1_8v" might be the best way out
vishnup has joined #linux-sunxi
flok420 has joined #linux-sunxi
Ueno_Otoko has joined #linux-sunxi
akaizen has joined #linux-sunxi
bfree has quit [Ping timeout: 256 seconds]
cptG has quit [Ping timeout: 260 seconds]
p1u3sch1 has quit [Ping timeout: 265 seconds]
cptG has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
TheSeven has quit [Ping timeout: 250 seconds]
akaizen_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
TheSeven has joined #linux-sunxi
cptG has quit [Ping timeout: 260 seconds]
cptG has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 240 seconds]
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
cptG has quit [Ping timeout: 240 seconds]
cptG has joined #linux-sunxi
akaizen has joined #linux-sunxi
akaizen_ has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
_stephan has joined #linux-sunxi
Ueno_Otoko has joined #linux-sunxi
vishnup has quit [Quit: Connection closed for inactivity]
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
vishnup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
domidumont1 has joined #linux-sunxi
yann|work has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
yann|work has quit [Ping timeout: 260 seconds]
cptG has quit [Ping timeout: 272 seconds]
cptG has joined #linux-sunxi
Quintus23M has joined #linux-sunxi
<Quintus23M>
apritzel: I was able to use your image file and inserted a first HypriotOS rootfs (Debian Jessie) and could successfully boot it on Pine64. Great work, thanks a lot!
Ueno_Otoko has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
hehopmajieh__ has quit [Remote host closed the connection]
lamer14534031262 has quit [Ping timeout: 250 seconds]
<libv>
this image crap is putting linux-sunxi further back.
<libv>
4y ago, i only had android devices to play with lima with
<libv>
and people then too were swapping image and doing just simplistic things and never ever collected information sensibly.
<libv>
with linux-sunxi we changed that.
<libv>
do not throw that away.
avph has quit [Ping timeout: 245 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
domidumont1 has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
<yann|work>
any idea what I overlooked, that would explain the lack of /dev/dri on Orange Pi Plus ?
<mripard>
they're not using DRM ? :)
<yann|work>
looks like there should be somehow a mali_drm driver somewhere - can't find anything related in drivers/gpu/mali
tgaz has quit [Ping timeout: 250 seconds]
lamer14534031262 has joined #linux-sunxi
tgaz has joined #linux-sunxi
apritzel has joined #linux-sunxi
tgaz has quit [Read error: Connection reset by peer]
whitesn has quit [Ping timeout: 276 seconds]
tgaz has joined #linux-sunxi
whitesn has joined #linux-sunxi
whitesn has quit [Changing host]
whitesn has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<yann|work>
ah, found the stuff in modules/mali/ in the source - but I'm puzzled by those apparently not being handled by the standard kernel/modules build procedure, and not seeing any specific info about them in the wiki either
enrico_ has joined #linux-sunxi
domidumont has joined #linux-sunxi
Net147 has quit [Ping timeout: 256 seconds]
Net147 has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 245 seconds]
hipboi has quit [Quit: This computer has gone to sleep]
qt-x has joined #linux-sunxi
Worf has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 245 seconds]
iamfrankenstein has joined #linux-sunxi
jbrown has quit [Remote host closed the connection]
vishnu_ has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 256 seconds]
iamfrankenstein has joined #linux-sunxi
jbrown has joined #linux-sunxi
<MoeIcenowy>
it seems that for mali driver higher than r4
<tkaiser>
libv: 'this image crap' has to happen for Pine64/Pine64+ since the Pine guys only take care of their Android release
<libv>
yes, but still, try to get away from those asap
<libv>
and you should get code from them.
<MoeIcenowy>
to be honest
<libv>
otherwise pull the emergency break and shout "GPL violation"
<libv>
brake even
<MoeIcenowy>
the lichee kernel of a33
<MoeIcenowy>
its disp driver cannot have flash cursor
<MoeIcenowy>
(in fb console mode
<libv>
tkaiser: do i need to step in and cry foul and get them to clean up their act?
<tkaiser>
libv: I bet in a month there will be +10 'Linux OS images' for Pine 64 based on the Android image, using 3.10.65 kernel and any rootfs of choice. The most popular being a Raspbian rip-off with ARMv6 userland stuff ;)
<tkaiser>
AFAIK they provide the 'BSP'
<libv>
tkaiser: but this is exactly what sunxi should avoid
<tkaiser>
I know but will this change anything?
<libv>
it's why it is here, and has been here for 4ys and why everyone today depends on sunxi
<libv>
tkaiser: sounds like i need to get nasty again.
<MoeIcenowy>
at least we don't need to RE everything
<libv>
MoeIcenowy: yes, we should so praise ourselves lucky that nothing has changed in 4ys
<MoeIcenowy>
ys = years?
<libv>
oh no, we only helped create a market for sunxi based dev boards
<libv>
and now get to pay the price again.
<MoeIcenowy>
libv: maybe
<MoeIcenowy>
(although I'm now a lichee user
<libv>
we need to get away from images asap, and write up how to get things set up with the sdk, then we can think about mainline
<apritzel>
a stray line break, making make complain
<apritzel>
my impression that the "BSP" is actually an old dump during the development
<yann|work>
MoeIcenowy: in my case it is r4p0 (from ssvb's h3 branch), and there is mali_drm source
<apritzel>
MoeIcenowy: aarch64 el1 == svc: for a starter: yes
<tkaiser>
apritzel: I would believe the same. I also found it strange that in their forums a user asking for 'are we able to build Android ourselve?' was also pointed to this tarball while they announced a new Android build with several fixes at the same time.
<apritzel>
tkaiser: right, I was wondering about that one too
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
<tkaiser>
So there's somewhere sitting around (maybe at Allwinner) having code that works more or less and the publicly released tarballs are outdated stuff
<apritzel>
In general I don't pay so much intention to this BSP crap
<apritzel>
eventually we are going to replace this anyway
<apritzel>
and this way this BSP is written has no future
<MoeIcenowy>
yann|work: my a33 code have no
<MoeIcenowy>
apritzel: thx
<MoeIcenowy>
apritzel: and el3 == hyp?
Quintus23M has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<apritzel>
no, EL3 = monitor mode
<apritzel>
EL2 is HYP
<apritzel>
Linux runs in EL1, switching to EL2 from time to time when KVM is involved
<apritzel>
similar to the HYP switch in arm32
<apritzel>
but for this to work it has to be started in EL2 (to install a handler)
viccuad has joined #linux-sunxi
viccuad has quit [Client Quit]
<apritzel>
has anyone looked at a U-Boot port yet?
<apritzel>
I am tempted to have a look, but am totally busy with day job and Linux bringup
<yann|work>
MoeIcenowy: in fact I may be confused by the role of the modules/mali/ tree - even for mali.ko there are sources in there (for r3p2 and r4p0), but what's used by the build is a different source code, in drivers/gpu/mali/mali
<yann|work>
and yes, there is no mali_drm in the latter, only in the former
SadSmile has quit [Remote host closed the connection]
vishnu_ has joined #linux-sunxi
<wens>
apritzel: fyi arisc code is loaded at 0x40000 because 0x40000 ~ 0x41000 is the interrupt vector, of which only the first byte of each 0x100 block is valid
<wens>
this is shown in the a33 memory map
<apritzel>
wens: right, know that you say this I remember
<tkaiser>
apritzel: At least Allwinner's 3.10.65 kernel can be built using the lichee BSP: http://pastebin.com/whEK1cHG
<apritzel>
but this seems to be missing in the A64 doc
<wens>
since they are reusing a lot of the design, it is likely the same :)
<tkaiser>
So I bet we see in a weak the first 'Pine64 Linux images' running based on the Android image and this kernel ;)
<apritzel>
tkaiser: but that's just the kernel, right?
<mripard>
wens: not the first byte, the first word
<apritzel>
only this kernel will not run with the current firmware
<apritzel>
because it unconditionally accesses EL2 and EL3 registers
<tkaiser>
Ah, nice ;)
<apritzel>
I don't care about the kernel at all, frankly
<tkaiser>
I know
<apritzel>
but being able to re-compile their u-boot (enabling all the missing stuff) would help a bit
<wens>
mripard: ah, right :)
iamfrankenstein1 has joined #linux-sunxi
reinforce has joined #linux-sunxi
<wens>
apritzel: there's also the possibility that the missing stuff doesn't work :|
<apritzel>
wens: good point ;-)
<apritzel>
but just being able to use fatload or extload would help quite a bit already
<wens>
i agree
* apritzel
is checking on the status of my application for the 28h day
Quintus23M has quit [Ping timeout: 240 seconds]
<wens>
28h day?
<plaes>
A10/A20 doesn't have HW w1?
<plaes>
actually, which SoCs do have HW w1 support?
<plaes>
A31/A23?
<plaes>
ok, A31 has it
<plaes>
not present in A33
<plaes>
not in H3
iamfrankenstein1 has quit [Ping timeout: 276 seconds]
<mripard>
plaes: A31, A80 at least
<plaes>
yeah, didnt see it in A64 nor A23 either
IgorPec has joined #linux-sunxi
ssvb has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
<plaes>
mripard: thanks ;)
<plaes>
..for fixing my typo
<apritzel>
wens: 28 hours per day to get more stuff done ;-)
<KotCzarny>
you need outsourcing then
<plaes>
ok, I rehashed 1-Wire wiki page a bit
<plaes>
complaints welcome
<yann|work>
ssvb: I'm wondering where the mali_drm stuff come from in your branch's modules/mali/*, and what the reason can be not to get a version in drivers/gpu - any hint ?
<yann|work>
(on branch 20151207-embedded-lima-memtester-h3, that is)
<mripard>
plaes: thanks for the 1-wire page
<yann|work>
can't find it on malideveloper.arm.com, they may come from somewhere else ?
<ssvb>
yann|work: it is a copy of the mali drivers from the sunxi-3.4 kernel (a10/a13/a20)
<ssvb>
yann|work: "what the reason can be not to get a version in drivers/gpu" - what do you mean by that?
<yann|work>
having a drm_mali driver built
<yann|work>
I mean, fbturbo seems to want one, and loboris builds it from modules/mali
<ssvb>
yann|work: yes, try to enable it in the kernel config
<yann|work>
you mean just picking the driver from sunxi-3.4 should be ok ?
<apritzel>
KotCzarny: it's not only the result I am interested in, it's also the process of getting there that is good part of the fun ;-)
<yann|work>
oh I see, it was part of r2p4, but was dropped in r3p0
Ueno_Otoko has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
Ueno_Otoko has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
vishnup has quit [Quit: Connection closed for inactivity]
cnxsoft has quit [Quit: cnxsoft]
domidumont has joined #linux-sunxi
<yann|work>
ssvb: fbturbo works much better with the driver added :)
<KotCzarny>
which driver, mali?
<yann|work>
mali_drm
<vishnu_>
mripard: sunxi_pinctrl_gpio_to_irq fails in case of pin which is configured as gpio interrupt and do not have irq function.
<ssvb>
yann|work: do you run some 3D applications?
<vishnu_>
for gpio interrupt pin, does it necessary to have "irq" function?
<mripard>
vishnu_: yes
<vishnu_>
for A83T,
<vishnu_>
PF6 on a board is mmc CD pin, and it's does not have "irq" function
<yann|work>
ssvb: yes
<yann|work>
will try more, just tested an in-house app for now
<ssvb>
yann|work: ok, that's good to know
<mripard>
vishnu_: iirc, the MMC layout can poll on a GPIO
<yann|work>
doing a bit of glmark now
<ssvb>
apritzel: finally got my Pine64 board
<apritzel>
ssvb: wohoo!
<mripard>
vishnu_: but you can't use an IRQ
<wens>
"broken-cd" property?
<apritzel>
ssvb: are you planning on doing some U-Boot work on it anytime soon?
<ssvb>
apritzel: it is pretty large, quite a bit bigger than many other ARM boards that I have, despite the kickstarter claiming "PINE A64 is Small" :-)
<apritzel>
ssvb: Yes, that was my first impression, too! ;-)
<ssvb>
apritzel: yes, I will try to hack something
<MoeIcenowy>
yann|work: Mali binary driver is terrible
<wens>
ssvb: i assume you don't have any a80 boards :p
<MoeIcenowy>
and not suitable for production libEGL/GLES implementation
<wens>
ssvb: or any boards from merrii
<MoeIcenowy>
as it cannot even support GPU sharing between two processes
<MoeIcenowy>
I started a gdm with mali
<MoeIcenowy>
and a gnome-shell cannot then be started with mali
<mripard>
wens: afaik, broken-cd is for when you don't have a card-detect
<mripard>
not when you have one that cannot use interrupts
<mripard>
but I guess it would work yeah
<apritzel>
ssvb: I guess you aim at an arm64 U-Boot port? Let me know if you need help or advice ...
<ssvb>
apritzel: I guess, I will initially try to make it work in the same way as the older allwinner boards and boot a 32-bit kernel first
<apritzel>
ssvb: interesting exercise, I was wondering about that too
<apritzel>
in fact I deliberately kept the DT 32-bit compatible
viccuad has joined #linux-sunxi
<vishnu_>
mripard: then how to tell mmc driver which pin to poll?
<apritzel>
(it's mostly about the /cpus #address-size being <1> instead of <2>)
<apritzel>
ssvb: though I am not sure whether we should waste^Winvest time on a 32-bit port
<apritzel>
as ultimately we want a 64-bit U-Boot
<yann|work>
MoeIcenowy: oh, yeah, that sounds nice :)
<apritzel>
I have some ideas on how to boot 32-bit kernels from it anyways
<ssvb>
apritzel: it does not look like a very difficult exercise, and we need take care of the DRAM initialization
<apritzel>
do we?
<MoeIcenowy>
yann|work: nice?
<MoeIcenowy>
are you kidding me?
<apritzel>
ssvb: can't you just take it from where boot0 drops you?
<yann|work>
MoeIcenowy: that was supposed to be ironic ;)
<ssvb>
apritzel: well, I prefer to have no blobs
<MoeIcenowy>
such a libGLES implementation cannot even be used in a desktop system!
<wens>
mripard: well, "broken-cd" sets a flag, which is also set if gpio_to_irq fails
<apritzel>
ssvb: in the long run I agree, but I guess implementing the whole SoC init ourselves would take some time
<ssvb>
apritzel: I've been in contact with the Pine64 people and they have talked to some Allwinner people about the DRAM initialization code
<yann|work>
we could argue the focus more on embedded devices than desktop, but well...
<wens>
letting the core fallback is better though
<ssvb>
apritzel: I just need to see where we are now and what exactly to ask from them
<ssvb>
apritzel: I guess, the libdram source code with GPL license headers is all that we need
<wens>
vishnu_: cd-gpios DT property tells the mmc core which pin to poll
<mripard>
wens: ah, ok
<wens>
vishnu_: if it fails to convert to irq, it just polls it
<apritzel>
ssvb: don't get me wrong: I very much appreciate this all-open-stack approach
<apritzel>
ssvb: I just assume that it takes much longer
<vishnu_>
wens: great, "cd-gpios" with "broken-cd" will do the work.
naobsd has joined #linux-sunxi
<apritzel>
ssvb: and I'd rather have something half-way sane (64-bit U-Boot) quickly and then take it from there
<apritzel>
from a user perspective using boot0 or the U-Boot SPL shouldn't make so much of a difference
paulk-collins has joined #linux-sunxi
<apritzel>
but if we are stuck with that shitty U-Boot for a while, this will anyone everyone
<vishnu_>
wens: sorry, but as per mmc bindings only one property must be supplied.
<yann|work>
MoeIcenowy: anyway, knowing this is good, but what alternatives do we currently have ? I've understood lima is not advanced enough to be useful, right ?
<wens>
vishnu_: just use cd-gpios
<wens>
vishnu_: if the gpio fails to convert to irq, mmc core will switch to polling
<MoeIcenowy>
yann|work: for a desktop, if you do not care 3d experience a lot, but want a useful desktop
<MoeIcenowy>
llvmpipe may be a good choice
<MoeIcenowy>
I'm not joking
<ssvb>
apritzel: for example, A80 does not have SPL yet, and look how happy are the end users
<vishnu_>
wens: Okie, that's why I was wondering how it detects removal even if it failed to convert to irq. ;)
<ssvb>
apritzel: with all the other boards, building U-Boot and installing it is pretty straightforward and well documented
<ssvb>
apritzel: moreover, the DRAM initialization is a potential reliability hazard, so it's better to have full control over it
<apritzel>
I see, I just don't like the general idea of U-Boot also being firmware as well too much
<apritzel>
it should just be a boot loader
<apritzel>
for instance we would need to somehow inject the PSCI code in there
Ueno_Otoko has joined #linux-sunxi
<apritzel>
which is coming from ARM Trusted firmware - which isn't the worst approach, tbh
<wens>
don't see any support for that in u-boot armv8
<apritzel>
that's what I mean
<apritzel>
normally on arm64 the boards/server provide PSCI firmware
<apritzel>
you should look at RK3368
<apritzel>
they should have a similar problem
<wens>
iirc PSCI for u-boot armv7 is only supported on a few chips
<apritzel>
because it's bascially a RK3288 (which is 32-bit) with A53 cores
<apritzel>
well, the implementation is rather generic
<apritzel>
thanks to maz_
<apritzel>
you just need to wire it up
<apritzel>
provide platform specific hooks for CPU_ON and CPU_OFF, basically
<wens>
i know, i did the rest based on his version for the a20
<apritzel>
wens: Oh, I C
<apritzel>
(and I did the step before with the HYP switch ;-)
<yann|work>
MoeIcenowy: llvmpipe is software only, right?
<ssvb>
apritzel: did you have much progress with USB on A64?
<apritzel>
ssvb: couldn't try that yet, but it shouldn't be so much of a problem
<apritzel>
in the moment I try to use a proper DT
<apritzel>
instead of my hacked one
<apritzel>
the "proper" DT I have doesn't boot so far, once I fixed that, I will tackle USB
<apritzel>
ssvb: shall I send the two DTs to you for reference?
<ssvb>
apritzel: just push them to some branch and add a link to it in the wiki
<MoeIcenowy>
yann|work: yes
<MoeIcenowy>
currently I use llvmpipe for desktop
<MoeIcenowy>
and mali is for specified programs
<apritzel>
ssvb: I wanted to avoid pushing broken WIP branches, but let's see
<yann|work>
MoeIcenowy: ah ok - so it's not really worth looking at it when one only plans a single-app appliance, but I'll keep that in mind
<wens>
the arm trusted firmware docs make my head spin...
Worf has quit [Quit: Konversation terminated!]
domidumont has quit [Quit: Leaving.]
orly_owl has quit [Ping timeout: 260 seconds]
qt-x has quit [Quit: Leaving]
domidumont has joined #linux-sunxi
<apritzel>
wens: yeah, it's meant to support massive systems
<apritzel>
if you have just one cluster (as we do), then you actually don't need most of it
<apritzel>
wens: I can take care about a proper port of that to Allwinner
<apritzel>
later ;-)
<GeneralStupid>
i had problems with usb (we talked about irq on smp systems and so on...) But i guess it was a power supply problem. Now i added a powered usb hub
<GeneralStupid>
and it looks fine
<TheLinuxBug>
yeah you need to be careful about the cable you use and the adapter as well
<TheLinuxBug>
I bought my cubieboard a10 with an adapter
<TheLinuxBug>
which advertised at 5v2.1a
<TheLinuxBug>
but really only put on about 5v 1.8a
<TheLinuxBug>
and couldn't get a drive to work on it for my life
<TheLinuxBug>
its real picky about it
<TheLinuxBug>
also if your using adapter with USB cable
<TheLinuxBug>
not all USB cables are made alike
<TheLinuxBug>
and quality matters for power transport
<TheLinuxBug>
ive had bad usb cables like that
JohnDoe_71Rus has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<GeneralStupid>
TheLinuxBug: i only measured the current and it goes down to 4.5 Volts
<tkaiser>
GeneralStupid: You meant the voltage? That's most of the times the real problem: Increasing consumption leading to undervoltage situations:
<rds>
montjoie: have you shared your Eth driver for H3 anywhere ?
diego_r has quit [Quit: Konversation terminated!]
<rds>
montjoie: I think the H3 users are growing faster, and if you share the driver, like folks that wrote the HDMI did it, you may have more folks debugging and testing
<rds>
just a thought!
<rds>
I may have a bit of time this weekend to look at it, if you like it
domidumont has quit [Read error: Connection reset by peer]
<MoeIcenowy>
Can we hope the support of Olimex's A64 devices is better than Pine64>
<wens>
tkaiser: trying to come up with an answer...
<apritzel>
MoeIcenowy: ideally just a rather small olimex_a64.dts ...
<apritzel>
at least Linux wise
<tkaiser>
wens: Do I understand it right that if Olimex provides this power switching then together with the appropriate code their A64-OLinuXino would be the first sunxi SBC exceeding 25MB/s accessing SD cards? Or is this only about eMMC?
orly_owl has joined #linux-sunxi
<wens>
tkaiser: both
<wens>
apritzel: depends on which kernel you use :p
<apritzel>
wens: there is only one kernel to rule them all ;-)
<apritzel>
I deny the existence of Linux-3.x kernels except for articles about Linux history ;-)
<wens>
looking at the new dts from them, i wish they stuck with fex :(
<apritzel>
I would exchange a .dts for a board ;-)
<wens>
i think olimex misunderstood me
matthias_bgg has left #linux-sunxi ["Leaving"]
p1u3sch1 has quit [Ping timeout: 245 seconds]
p1u3sch1 has joined #linux-sunxi
<tkaiser>
I hope they listen to you. It seems crucial to me to get the best MMC performance when they want to build a whole laptop around the board since USB is somewhat limited with A64
<apritzel>
wens: does Olimex provide a .dts already? Or are you talking about one from a BSP?
<tkaiser>
apritzel: wens talked about Allwinner ;)
<apritzel>
oh, who is Allwinner? ;-)
<wens>
apritzel: the one from the BSP :)
<apritzel>
wens: yeah, this one is really fun!
<apritzel>
it got much better once I typed: "fdt rm /soc; fdt rm /clocks" on the U-Boot prompt
<tkaiser>
Maybe just the product of fex2dts used internally? ;)
rds has quit [Ping timeout: 252 seconds]
IgorPecovnik has joined #linux-sunxi
IgorPecovnik has quit [Client Quit]
IgorPec has joined #linux-sunxi
avph has quit [Ping timeout: 245 seconds]
avph has joined #linux-sunxi
<yann|work>
ssvb: glmark2-es2 only gets 47, it should get higher, no?
<MoeIcenowy>
yann|work: what SoC?
<yann|work>
H3
<MoeIcenowy>
my A33 is alkie
<MoeIcenowy>
alike
<MoeIcenowy>
maybe you need to disable a option in fbturbo
<cptG>
I see USB otg has been mainlined in the form of the musb driver, while it seems it was (ugly) allwinner-code in 3.4.103 - does musb allow for more than just the g_ether module? Does mass storage or even the ConfigFS (FunctionFS?) work with musb?