<Net147>
ah I need to put as child node of regulators. axp209 -> regulators -> vcc_csi0: ldo3
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<Net147>
okay now the board shuts down when trying to start the kernel...
Putti has joined #linux-sunxi
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
fire219 has quit [Read error: Connection reset by peer]
dearfibonacci has joined #linux-sunxi
reinforce has joined #linux-sunxi
<KotCzarny>
maybe its used for something else too
<KotCzarny>
hmm, ' No problems known or worth mentioning. ' for a20 gpl, so dram/hdmi is supported?
<wens>
KotCzarny: dram code in u-boot is based on allwinner sources, with a proper gpl license
<wens>
i think that was from before i joined
<KotCzarny>
wens, werent there libdram issues or they are using it in a way that avoids violation?
<wens>
KotCzarny: iirc they released the source for libdram under the gpl
<KotCzarny>
thats good
<wens>
and before that that had boot0/boot1 blobs
<wens>
so no violation there
<wens>
as for hdmi, a quick look in their official repo shows no copyright headers for the hdmi bits, though proper gpl headers exist in the other parts of the display driver
<wens>
and the old hdmi controller is documented anyway
<Net147>
wens: I got the GPIOs working. I didn't have to do any changes to the kernel DT.
<wens>
KotCzarny: given major differences in how the display driver is structured, it's unlikely you could port allwinner's driver directly onto drm
<wens>
Net147: what was the issue then?
<KotCzarny>
uhum
<Net147>
wens: it looks like the GPIOs don't work in v2016.05. I updated u-boot to v2016.09-rc2 (which sets LDO3 and LDO4 to 2.8V) and it works now.
<Net147>
wens: v2016.05 sets LDO3 and LDO4 to 0V
<Net147>
wens: it looks like setting the LDO3 and LDO4 voltage in the kernel DT afterwards causes a hang or board shutdown for some reason...
ricardocrudo has joined #linux-sunxi
<Net147>
wens: GPIOs also working with u-boot v2015.04
sarietta has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 265 seconds]
foxx__ has joined #linux-sunxi
<jonkerj>
OK, I've confirmed i2c works on H3
<jonkerj>
I've patched DT, connected a simple si702x board to opi+ expansion header, compiled this hack [1] and it correctly prints out humidity and temperature
<plaes>
IIRC it wasn't applied because we don't want to enable all the buses by default on boards
<jonkerj>
sounds very reasonable
<jonkerj>
but uart2-3 and i2c0-3 should be at least available on H3
<jonkerj>
so people can enable to their liking
<plaes>
yeah.. they should be in dtsi
foxx__ is now known as foxx_
<plaes>
but disabled by default
<jonkerj>
I see martin has made a new patch (v2) in april '16, and maybe even a v3 (cannot find it on ozlabs), unclear to me what happened next
<jonkerj>
oh even a v4
<plaes>
when was v4 posted?
<jonkerj>
5 may
<plaes>
hrm.. no search :S
sarietta_ has joined #linux-sunxi
<plaes>
which mailinglist had v4?
<plaes>
ah.. all of them
<plaes>
mripard: o-
<plaes>
mripard: apparently some h3 I2C patches have slipped through cracks (sent on May 5th)
<plaes>
wens: ^^
<jonkerj>
jeah
<jonkerj>
tnx :-)
<plaes>
"dts: sun8i-h3: add missing UARTs pins and I2C entries for AllWinner H3"
* jonkerj
would gladly send his, but it seems fair to have martin strike with the honours
pg12 has quit [Ping timeout: 250 seconds]
MiLeon has joined #linux-sunxi
pg12 has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<jonkerj>
ah, I see a problem with Martin's patch. He adds UART1-3, while they are already present in H3. uart2-3 lack pin definitions, though
<jonkerj>
i2c is totally lacking
<plaes>
someone added uarts later
<jonkerj>
I'm going to mail this guy and check with him if he's going to do a v5, or have me do it
<jonkerj>
if I find his mail, all mail2web things obscure mailadresses a bit too good
<plaes>
I can give you if you want
<wens>
already msgd
<jonkerj>
tnx
<wens>
afaik his series wasn't accepted because he added pinmux nodes that no boards were using
OverCR has joined #linux-sunxi
<plaes>
I don't see any replies for v4
<jonkerj>
wens: is that strictly required?
<jonkerj>
makes (my) life a lot easier if the pinmux defs are "ready for action"
<wens>
jonkerj: it's meant to keep the dts small
<wens>
plaes: v4 might've fallen through the cracks
<jonkerj>
would it be OK to have those UARTs/I2Cs tied to the pinmux defs, but have the controllers themselves disabled?
<jonkerj>
for instance, on my board (opi+), UART1-3 and I2C0-2 are exposed on the generic expansion header
<jonkerj>
but those pins are usable as GPIO
<plaes>
wens: dtsi stuff should be included
<jonkerj>
or TWI, or sometimes even both
<jonkerj>
wens: would it be acceptable to do a thing like this: "&uart1 { pinctrl-bla = <uart1_pins_a>; status = disabled }" in the DTS, and put the pinmux in the DTSI?
sarietta_ has quit [Remote host closed the connection]
<jonkerj>
that should leave options open for the expansion header, while making it very easy for people (like me) to enable it with just one FDT command in uboot
<jonkerj>
(or an overlay)
apritzel has joined #linux-sunxi
<wens>
plaes: the controller nodes, yes, the pinmux settings, maybe not
<wens>
jonkerj: i had a couple of patches enabling "standard rpi compatible" peripherals for bpi boards, and listing others that are available on the headers, but disabled
<wens>
i don't think i upstreamed them though
<wens>
can't seem to find them right now
<jonkerj>
but the concept does not violate DTS/kernel guidelines?
popolon has joined #linux-sunxi
wens has quit [Remote host closed the connection]
wens has joined #linux-sunxi
Net147 has quit [Excess Flood]
foudubassan has joined #linux-sunxi
Net147 has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
wens has quit [Ping timeout: 260 seconds]
wens has joined #linux-sunxi
shirasaka-hazumi has quit [Remote host closed the connection]
huawei has joined #linux-sunxi
florianH has joined #linux-sunxi
MiLeon has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
vickycq- has joined #linux-sunxi
WeblordPepe has quit [Quit: leaving]
vickycq has quit [Ping timeout: 244 seconds]
afaerber has joined #linux-sunxi
<oliv3r>
wens: hi; i'm just going over your patch (history) of the rtl8211cl force master patch
<oliv3r>
why did you choose to do it via a global define, rather then a chip-specific quirk for example? Reason i'm asking, you say in the commit message, that you can now force master mode based on the board used
<oliv3r>
but we have 2 lime2's types in the wild now, featuring the different PHY's
<oliv3r>
they have seperate revisions (rev.E vs anything before) but it makes life difficult. is there no way we can detect this?
<oliv3r>
i was thinking, of checking (adding?) quirkcks to the struct phy_driver, or would that also fail?
<oliv3r>
.features maybe, anyhow, the alternative of course is to have two seperate bootloaders for lime2.revE and before
<oliv3r>
which would be nice if it could be avoided
<oliv3r>
ideally, we'd want to blacklist the RTL8322CL, but if not possible, whitelist the ones that are proven to work okay
<speakman>
I can't really wrap my head around the fact that Mali400 can't be used with more recent kernels. Why don't Allwinner just publish a newer fresh Mali driver?
<oliv3r>
speakman: that would require allwinner to put in effort towards that regard, and what is their net gain on that?
<oliv3r>
:)
<speakman>
oliv3r: well, I guess I just have to accept that point of view. :)
<speakman>
It's just so frustrating. :/
tkaiser has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<oliv3r>
that it is :)
premoboss has joined #linux-sunxi
utente_ has joined #linux-sunxi
premoboss has quit [Ping timeout: 255 seconds]
<wens>
mediatek x20 96boards goes for $199... wow
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
MiLeon has joined #linux-sunxi
Net147 has quit [Quit: Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
<_mamalala_>
tkaiser: hey, i think mali support in armbian is broken!! i want to accelerate my gpio pin toggling, but for some reason mali doesn't do squat there!!one!!eleventy!
* _mamalala_
ducks
<tkaiser>
wens: Too cheap?
<tkaiser>
_mamalala_: Wait for deca-core H5. With Mali450 and 6 cores your GPIOs will toggle flawlessly again
<_mamalala_>
:P
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
Da_Coynul has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<wens>
tkaiser: to be fair the a80 was released at a higher price, then slashed to half
Net147 has joined #linux-sunxi
popolon has quit [Ping timeout: 244 seconds]
Net147 has quit [Quit: Quit]
<tkaiser>
wens: Can the 2 CPU clusters on A80 used in HMP mode? That's what I also wonder regarding this Deca-Core thingie. How many CPU cores can run at the same time?
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<apritzel>
tkaiser: on almost every modern SoC all cores can work at the same time
<apritzel>
this "only one cluster at once" was just an annoying "implementation detail" of some early Samsung cores, AFAIK
<_mamalala_>
tkaiser: deca? i think the a80 is octa-core, no?
Net147 has joined #linux-sunxi
<wens>
tkaiser: why can't they?
<apritzel>
tkaiser: did you switch into marketing and add GPU and CPU cores? ;-)
Net147 has quit [Remote host closed the connection]
<tkaiser>
Was referring to Mediatek's X20 board: 2 x A72, 4 x A53 and another 4 A53. Given the overheating problems we already face with quad- and octa-cores I simply don't believe in this 'as many cores as possible' BS any longer ;)
Net147 has joined #linux-sunxi
<_mamalala_>
ah, ok
<tkaiser>
All 10 cores can be used when clockspeed will be adjusted to 480 MHz :)
IgorPec has joined #linux-sunxi
<tkaiser>
While people buy devices based on this SoC caused by marketing's 'Cortex A72 cores @ 2.1~2.3 GHz'
Da_Coynul has joined #linux-sunxi
<_mamalala_>
well, it makes a huge difference how a boardlayout is done ... a lot of thermal management can be done there, but i doubt that cheap chinese boards bother much about that
<_mamalala_>
plus, you very likely don't get away with a simple 4-layer board if you want good thermal management ...
paulk-nyan-big has joined #linux-sunxi
<tkaiser>
_mamalala_: apritzel could tell. With his BPi-M64 maximum clockspeed when running cpuburn-a53 might be reduced to below 408 MHz (compared to 600 on Pine64)
<_mamalala_>
what a shame then ...
<tkaiser>
Just an assumption based on the thermal design of BPi-M3 and now M2+
<apritzel>
tkaiser: also what annoys me about that "core-bragging" is that the rest of the SoC usually does not catch up with that theoretical computing power
<apritzel>
in terms of memory and I/O bandwidth, for instance
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<tkaiser>
apritzel: Sure, but the tablet/OTT box SoCs we deal here are sold to clueless people and the only marketing differentiation is count of (less interesting) CPU cores and GHz. It gets as dumb as back in Pentium IV days in ARM land now. At least when looking at this market segment.
<wens>
heard somewhere that the 2 quad-core clusters have different designed optimal clock rates, as in the actual silicon gates are optimized for some speed range
<_mamalala_>
agree ... most people are just unaware that it requires quite some good programming to actually make good use of multiple cores
IgorPec18 has joined #linux-sunxi
<_mamalala_>
expecting that using some obscure compiler switch will do it ...
IgorPec18 has quit [Client Quit]
<_mamalala_>
but then, it's quite clear that many people don't even grasp the stuff about hardware acceleration either, so i guess we can't expect them to understand stuff about cores anyways
<tkaiser>
wens: But then the 'normal' use case for the 3 different clusters is to choose between and not run all at the same time (in Android, in a smartphone or tablet)?
<_mamalala_>
usually, yes
<wens>
tkaiser: right
<wens>
tkaiser: still you could do hmp and let the scheduler figure out which core to put jobs on
<wens>
idle cores could be put into deep sleep
<tkaiser>
wens: Ok, but still people buy this thing since they think in numbers and 10 is more than 8. And are then surprised that the whole thing melts away when running on all cores.
<wens>
good argument for proper power/thermal management? :p
<tkaiser>
I played around with an octa-core board the last days. Used a NEON optimized Linpack and had to limit maximum cpufreq to 900 MHz since otherwise the Linpack triggers power-off through PMIC (or maybe my PSU is just too weak). It's not only about temperatures but also about consumption. And when the PMIC is not designed to deal with 10 CPU cores needing 15W then...
<_mamalala_>
well, no one stops the folks from plugging in a decent atx power supply, and adding a huge chunk of metal with big fans as a heatsink :P
<tkaiser>
_mamalala_: Hmm... if the SoC is designed to be accompanied by a PMIC then I would assume maximum current limits exist. And then your ATX supply is pretty useless (maybe only to destroy PCB traces)
<_mamalala_>
yeah, that's the question ... it could be that it is possible to run all cores at full power, given a beefy enough supply and good heatsinking ... or it could be that it is limited right away ...
<_mamalala_>
or they do it like early amd cpu's ... allow all cores to run at maximum, all the while the chip itself then just self-destructs because it can't handle it
<tkaiser>
NanoPi M3 combines Samsung/Nexell s5p6818 octa-core A53 with X-Powers AXP228, were too lazy to look up specs and fear that board layout might also be limiting.
<tkaiser>
wens: If I were you I would not order the X20 board but the Vernee Apollo Lite -- same price, more features! ;)
<_mamalala_>
"The phone is little slow to boot, as it typically does so in about one minute"
<_mamalala_>
wow, that _is_ slow
OverCR has quit [Read error: Connection reset by peer]
<_mamalala_>
but then, i noticed that with several smartphones and tablets ... they have ridiculously long bott times nowdays
<tkaiser>
_mamalala_: That's due to running on a Cortex-M4 in reality that activates one of the A53 cores from time to time. All cores are only used when execution of Antutu is detected.
OverCR has joined #linux-sunxi
<MoeIcenowy>
mripard: what's NextThing GR8?
formruga has joined #linux-sunxi
<MoeIcenowy>
is it a custom version of sun5i by aw?
<jelle>
MoeIcenowy: nextthing made the C.H.I.P., so a new chip :o
<jelle>
is there a tool to read dtb files?
<apritzel>
jelle: dtc?
<apritzel>
or from a running kernel?
<jelle>
apritzel: yesterday night I couldn't figure out why client->irq was 0, while I did set the interrupts = in my touchscreen block
<apritzel>
you can see what the kernel uses in /proc/device-tree
<jelle>
ohh
<apritzel>
(if that is configured)
<jelle>
I'll check that out tonight
<apritzel>
the .dtb is also in /sys/firmware/fdt for newer kernels
<jelle>
ok, but it's a blob right?
<apritzel>
or spelt out in /sys/firmware/devicetree
<apritzel>
/sys/firmware/fdt is the .dtb blob
<apritzel>
both /sys/firmware/devicetree and /proc/device-tree are directories
<apritzel>
which map DT nodes to UNIX directories and properties to files
<apritzel>
also note the dash in one path and the lack of it in the other - to confuse users ;-)
<jelle>
apritzel: thanks
Net147 has quit [Quit: Quit]
<jelle>
fully figured out one model of the zet62xx touchscreen
tkaiser has quit [Ping timeout: 265 seconds]
paulk-nyan-big has quit [Quit: Leaving]
Net147 has joined #linux-sunxi
Net147 has quit [Remote host closed the connection]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Sakami-_- has quit [Ping timeout: 252 seconds]
<mripard>
jelle: you can even use dtc to output a dts from /proc/device-tree
<jelle>
mripard: ok, cool!
jbrown has quit [Ping timeout: 276 seconds]
tkaiser has joined #linux-sunxi
Sakami-_- has joined #linux-sunxi
Amit_T has quit [Ping timeout: 240 seconds]
<wens>
tkaiser: those phones don't have good lte band support :/
jbrown has joined #linux-sunxi
<tkaiser>
wens: I was just kidding. At least they have a display! And eMMC! And some more stuff ;)
<lvrp16>
hi all
<MoeIcenowy>
Here's now a SBC discussing channel :-)
ninolein has quit [Remote host closed the connection]
<MoeIcenowy>
but it seems that Allwinner tablets are fewer and fewer in market...
<MoeIcenowy>
+-+*
Net147 has quit [Quit: Quit]
ninolein has joined #linux-sunxi
Net147 has joined #linux-sunxi
<jelle>
MoeIcenowy: not that many a64 ones? :)
paulk-collins has joined #linux-sunxi
<MoeIcenowy>
A64 tablets are now a little difficult to find
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
<jonkerj>
ah, mister Ayotte mails me that I'm free to propose a v5 for i2c/uart on H3, since he cannot find the time for it
afaerber has quit [Quit: Ex-Chat]
Net147 has quit [Quit: Quit]
<MoeIcenowy>
there seems to be some on alibaba...
popolon has joined #linux-sunxi
ninolein has quit [Remote host closed the connection]
<longsleep>
tkaiser: I had some converstaion with some pine64 users and the only use case with some chance to work was quake3 - if i did not give up at that point then i certainly did :)
<lvrp16>
i got my hands on some s912 boxes
<lvrp16>
they are not slow, just the heatsinks are crappy
ninolein has joined #linux-sunxi
<lvrp16>
the thing shoots to 90C in like a few seconds
<longsleep>
lvrp16: can you post a pic?
<lvrp16>
nexbox a1, it's at the office
<longsleep>
lvrp16: or how large is the heat sink?
<lvrp16>
tiny
<lvrp16>
like 5cm x 3 cm
<lvrp16>
x 0.75cm
<longsleep>
ah why does it come with one at all then
<lvrp16>
i know...
<lvrp16>
i talked to the nexbox people, i will help them design a new product end of the year
<lvrp16>
with a gigantic heatsink ;)
<lvrp16>
i feel like thats the biggest problem with sbc's these days
<lvrp16>
need a giant heatsink like odroids
iamfrankenstein has quit [Ping timeout: 260 seconds]
iamfrankenstein1 has joined #linux-sunxi
afaerber has joined #linux-sunxi
<longsleep>
yes the odroids is nice, the one from pine64 i got for testing is nice too but still does overheat after 4 to 5 minutes or so
<longsleep>
they do not want to make it larger so the whatever shields still can fit ..
enrico_ has joined #linux-sunxi
<lvrp16>
i am definitely going to spin some boards by year end for market next year
<lvrp16>
these sbc vendors are doing it all wrong
<lvrp16>
can't rely on them to get anything done
iamfrankenstein1 is now known as iamfrankenstein
<longsleep>
lvrp16: the s912 boxes you got, they have USB3 right?
<lvrp16>
uhh did not pay attention, i don't think so but i'll double check tomorrow
<longsleep>
would be interesting getting a cheap board with fast usb3
<lvrp16>
yeah i'm waiting for amlogic to get their mainline straight
OverCR has quit [Read error: Connection reset by peer]
<lvrp16>
i'll put out s912 sbc's myself
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<apritzel>
lvrp16: weren't you looking into a RK3399 based board?
<lvrp16>
yeah that's easy
* apritzel
was hoping for some PCI, at last
<lvrp16>
diversity is healthy
<lvrp16>
i will spin as many boards as there's the market for
<lvrp16>
but if a73 comes out quickly
<lvrp16>
i might skip one or the other
afaerber has quit [Ping timeout: 250 seconds]
OverCR has joined #linux-sunxi
<apritzel>
lvrp16: to be honest, I don't care so much about the actual cores used
<apritzel>
it's more about the rest of the SoC that sucks on most dev boards these days
<lvrp16>
you mean lack of pcie and usb3?
<lvrp16>
i want to have desktop class SBCs
<_mamalala_>
lvrp16: i'd like to see an h3 boad with only eth, usb and sd, while all the remaining io pins are on pinheaders ;)
<apritzel>
for instance
<apritzel>
what bugs me most is the lacking memory bandwidth and lack of decent mass storage
<apritzel>
M.2 SSD would be nice
<lvrp16>
memory controllers are expensive
<lvrp16>
especially shared memory controllers in SoC
<apritzel>
not really, I guess it's more about the pins needed for wider DRAM connections
<apritzel>
lvrp16: you mean: _good_ memory controllers are expensive?
<lvrp16>
yes
<lvrp16>
good dual channel memory controllers
<apritzel>
rk3399 comes with a dual channel DRAM interface, right?
<lvrp16>
yes, it supports up to 8GB
<lvrp16>
although i think sdk side they have only tested 4GB
jbrown has quit [Ping timeout: 265 seconds]
<lvrp16>
if only huawei lets people buy their 955
<lvrp16>
that chip makes me drool
Net147 has joined #linux-sunxi
afaerber has joined #linux-sunxi
jbrown has joined #linux-sunxi
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
ganbold has quit [Ping timeout: 240 seconds]
<KotCzarny>
dziekuje za nalesniczki
<KotCzarny>
\whoops. wrong chan
<apritzel>
KotCzarny: I hope they tasted well :-D
<KotCzarny>
as always ;)
pekka10 has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
tuxillo has joined #linux-sunxi
<tuxillo>
hey there
<tuxillo>
anybody knows if rpi3 can be booted from u-boot in aarch64 mode and take an image from tftp?
Net147 has quit [Read error: Connection reset by peer]
<apritzel>
tuxillo: slightly off-topic, I guess, but AFAIK there are images doing this, agraf should know
<apritzel>
at least I have seen U-Boot running in AArch64 on it
MiLeon has quit [Remote host closed the connection]
MiLeon has joined #linux-sunxi
dearfibonacci has quit [Quit: Leaving]
<tuxillo>
yeah, it's off topic, sorry. but I have gotten similar information in the past in this channel so I tried :)
Net147 has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 276 seconds]
cnxsoft has quit [Quit: cnxsoft]
<tkaiser>
longsleep: Did you get an LCD from Pine64 folks?
<zoobab_>
@tkaiser any idea if an armbian nanopi image would work on other h3, like orangepi one?
<tkaiser>
zoobab_: Works flawlessly unless you want to use exotic stuff on the expansion header (SPDIF for example)
<zoobab_>
great will try it
<tkaiser>
zoobab_1: The image for M1 needs no adjustments to run on OPi One with the NEO image you get a slower device (DRAM just clocked with 408 MHz there)
<zoobab_>
does armbian kernel has overlayfs enabled? I am looking to run docker on armbian
<willmore>
lvrp16 put the SoC on the bottom of the board and heatsink it to the whole case.
<lvrp16>
unless the case is made of copper, you will still have heat issues
<zoobab_>
the nanopi is nice, but shipping costs doubles the price of the board
<lvrp16>
10 cores like the x20 is a bitch to cool
<tkaiser>
zoobab_: Then you need mainline kernel images and can choose the one with 4.6.7 for NEO
<willmore>
lvrp16, cast or extruded aluminum?
<lvrp16>
needs to be pretty thick aluminum
<lvrp16>
most cases are less than 1mm
<lvrp16>
need at least 2-3 mm
<longsleep>
tkaiser: yes - didnt try it though
<willmore>
Gotta be better than a little tab of metal inside of a sealed plastic box.
<lvrp16>
true, i will keep that in mind
<willmore>
:)
<tkaiser>
zoobab_: BTW: there is more than one H3 NanoPi available. And at the moment I would stay away from the NEO unless you really need a very tiny board. Overheats too much and with reasonable settings slower than every other H3
<zoobab_>
I have 2 or 3 orangepi I ordered a year ago, I was waiting for mainline support for it, and ethernet took a loooong time to be added
<tuxillo>
tkaiser: which one?
<tkaiser>
zoobab_: Not true for me, one customer runs H3 GbE boards with 4.6-rc1 since April. I also had not that much problems with Fast Ethernet since months
<tkaiser>
tuxillo: What? Which? There is NanoPi M1, NEO and soon NEO-AIR. All H3 based
<tkaiser>
IMO Plus and Plus 2 are uninteresting since they use an internal USB hub and the crappy GL830 USB-to-SATA bridge. So OPi Plus 2E and BPi M2+ are remaining
<tkaiser>
But I don't know whether he's still on RTL8211CL or E
<tuxillo>
tkaiser: the lcd. nvm found it
<tkaiser>
oliv3r: And BTW I believe next Armbian release (nearly finished) is postponed since we're waiting for your DRAM testing on Lime2 ;)
willmore has quit [Ping timeout: 276 seconds]
willmore has joined #linux-sunxi
<lvrp16>
tkaiser do you want me to setup a lab with a relay controlled power?
<lvrp16>
that you can access remotely?
<lvrp16>
like what kernel-ci is doing?
<oliv3r>
tkaiser: lol wow :p
<oliv3r>
tkaiser: anyhow, i'll check the config, but what does he say 'makes it work'
<oliv3r>
i have no problems with the lime2 + emmc
<oliv3r>
works fine, been working since over a year now :p
<oliv3r>
the problem comes from the RTL8211E
<oliv3r>
i can run armbian fine on the board with LAN, but no EMMC obviously (script.bin doesn't know about emmc)
<oliv3r>
i can boot mainline fine from SD card and seee the emmc and use it
<oliv3r>
but if i boot from emmc, and run from emmc, lan stops working after about 2 minutes (some timer somewhere going off) and the STMAC driver keeps resetting
<oliv3r>
what baffles me now is, that i can boot 4.7.2 from SD, copy it to emmc, boot from eMMC which works, but then it cannot find the other partitions anymore
<oliv3r>
unless there was some re-enumeration fix making the eMMC appear on the same node, always
<oliv3r>
i haven't checked that
<oliv3r>
ohh it has been changed, that the eMMC device always is devicenode 1
<oliv3r>
okay, kinda cool
<tkaiser>
lvrp16: thanks, already wasting too much time with these devices. Have to focus on the essentials again :)
<tkaiser>
oliv3r: No idea then :)
<clever>
something i was wondering about with the EOMA specs, if you supply some external power, could the entire cpu module be hot-plugged?
vagrantc has joined #linux-sunxi
ganbold has joined #linux-sunxi
<oliv3r>
tkaiser: yeah pretty shitty :p
Ultrasauce has quit [Remote host closed the connection]
<wens>
clever: why would you hotplug the cpu module?
<clever>
wens: moving it from a laptop to a tablet to make the system more portable temporarily
<clever>
wens: without having to reboot it
ganbold has quit [Quit: Leaving]
<clever>
the bulk of the interfaces are hot-plugable like USB, so it will just need to detect the new DTB in the i2c eeprom, reconfigure the LCD interface, and reload anything dealing with GPIO
ganbold has joined #linux-sunxi
jbrown has quit [Quit: Leaving]
<oliv3r>
wens: is it a sunxi mmc change that causes an empty configured mmc socket to be properly enumerated?
<oliv3r>
hmm, might be higher up actually, very nice neverthless
<oliv3r>
ohh, maybe it's an LDO problem :S
netlynx has joined #linux-sunxi
<mripard>
clever: the i2c bus is not hot-pluggable, neither is the LCD interface, nor are the GPIOs
reinforce has quit [Quit: Leaving.]
<clever>
mripard: for the GPIO, i dont see why you cant just unload all related drivers and tri-state the pins on the cpu
<clever>
LCD, what stops you from re-configuring it after it gets plugged back in?
<clever>
i2c, you will need some way to detect the insertion, and then re-scan the eeprom addr and re-init the above
<clever>
checking for voltage from the dock end would work as insertion detection
<mripard>
afaik, it's not even safe at an electrical level
<clever>
yeah, thats a bit more tricky, what would have to be changed to allow it?
<clever>
put half of the i2c pullup resistor on each side of the docking port?
<mripard>
and since neither LCD nor I2C are supposed to be hot-plugged, I'm pretty sure you would deal with "caching" problems at the software level
<mripard>
at least for LCD it would be the case
<clever>
so both idle high and the pullup doesnt become larger
<clever>
LCD is purely output, i dont see how it can have caching problems
<wens>
because it isn't designed to be hotplugged, and probably the driver isn't either :p
netlynx has quit [Quit: Ex-Chat]
<clever>
hmmm, would it be safer to disable the pins from software first?
<wens>
there's still a possibility of shorting or otherwise frying something
<clever>
once you stop driving the pins and let them tri-state with pullups, there will be less current and transitions going on
<wens>
if the board and card were to be powered from different power sources and have different or reversed potentials
<wens>
or leaky power
<clever>
yeah, dealing with different +5v rails mixing would be tricky
<clever>
but another thought i just had might solve that
<clever>
what about suspend to ram, how much current does the dram take to maintain data?
<clever>
slap a small lipo in there?
<mripard>
clever: because of the EDIDs (or "emulated" EDIDs for the screen that support that)
<clever>
mripard: the software driving the lcd would have to be updated to accept new EDID data at runtime, like HDMI already does
scream has joined #linux-sunxi
<wens>
it is not a standard use case, good luck getting support on it :|
<clever>
wens: at this point, suspend to disk would be simpler, no hardware changes required
<clever>
purely a software fix
<wens>
suspend to ram is not supported
<wens>
can suspend to disk handle hardware changes?
<MoeIcenowy>
I think the answer is no...
<clever>
the kernel would have to be modified to rescan for that kind of change on startup
<clever>
or just unload all those drivers before suspending
<wens>
unlado all drivers and then what? you have not storage, no input lol
<clever>
the storage is on the cpu module, so that doesnt have to unload
<clever>
and it would be a script that unloads, suspends to disk, rescans i2c eeprom, loads drivers
<clever>
so loss of input doesnt come into play
<wens>
you're saying there's no mmc or nand pins going out onto the external board?
kronicd has quit [Read error: Connection reset by peer]
<clever>
you would need to umount any mmc/nand that is on the host board before suspending to disk
<mripard>
clever: the point is that even for HDMI it doesn't
<mripard>
or rather
<mripard>
it does, once, when it detects that the screen is connected
<mripard>
how do you know if the LCD is connected?
Putti has joined #linux-sunxi
<clever>
the LCD is described in the eeprom on the i2c bus
<clever>
so after it regains power over the main EOMA dock, rescan the eeprom, and configure the new LCD
<clever>
or if its using suspend to disk, do that while resuming
kronicd has joined #linux-sunxi
IgorPec has joined #linux-sunxi
reinforce has joined #linux-sunxi
utente__ has joined #linux-sunxi
utente_ has quit [Ping timeout: 265 seconds]
enrico_ has quit [Quit: Bye]
ricardocrudo has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 244 seconds]
apritzel has joined #linux-sunxi
petr has quit [Ping timeout: 276 seconds]
petr has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
popolon has quit [Ping timeout: 255 seconds]
<tuxillo>
agraf: got a moment?
sarietta_ has joined #linux-sunxi
alsy has joined #linux-sunxi
<alsy>
Can anyone explain me how the sun4i-drm driver can be activated on a cubietruck? And which xorg driver to use?
<plaes>
alsy: it currently cannot
<plaes>
a20 is not supported yet
JohnDoe_71Rus has joined #linux-sunxi
Ultrasauce has joined #linux-sunxi
<alsy>
Plaes: how much work is it to implement? If I understand it right, the difference between the A10 and the A20 GPU is that the A20 GPU is a dual-core GPU right?
<plaes>
A10 and A20 are the same
<plaes>
A13 is currently implemented
<alsy>
OK and what's the difference there?
<plaes>
A13 is somewhat simpler than A10/A20
afaerber has quit [Quit: Ex-Chat]
\\Mr_C\\ has quit [Quit: .]
buZz has quit [Quit: this is not my demise, i shall return]
putti_ has joined #linux-sunxi
Putti has quit [Read error: Connection reset by peer]
nemunaire has quit [Quit: quit]
putti_ has quit [Quit: Leaving]
Putti has joined #linux-sunxi
<plaes>
o_O nextthing made their own SoC?
popolon has joined #linux-sunxi
<alsy>
OK but why the GPU driver is called sun4i (A10) and not sun5i (A13)?
<plaes>
err.. GPU is actually Mali
<alsy>
That means? Does the actual sun4i-drm have 2D accel?
<willmore>
Has anyone else used a GC2035 camera module with an Opi1? I think I have it physically connected properly--like the photo on the linux-sunxi web site. I installed the modules gc2035 and vfe_v4l2 but /dev/video0 doesn't act like there's a camera attached.
<willmore>
Okay, updated to the current kernel and rebooted. Now it seems like it might be working....
<willmore>
Yep, that's an actual image. Yay!
<rellla>
Are there any specs of the great GR8 available? ;)
<miasma>
i started filling the board table with friendlyarm boards, but not sure about all the regulators and stuff so didn't fill them all in yet
IgorPec has quit [Ping timeout: 264 seconds]
IgorPec18 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec19 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 258 seconds]
foxx_ has quit [Ping timeout: 258 seconds]
IgorPec18 has quit [Ping timeout: 252 seconds]
MiLeon has quit [Ping timeout: 244 seconds]
buZz has joined #linux-sunxi
buZz is now known as Guest65078
andor2007 has joined #linux-sunxi
Guest65078 is now known as buZz
fire219 has joined #linux-sunxi
afaerber has joined #linux-sunxi
IgorPec19 has quit [Ping timeout: 276 seconds]
Putti has quit [Ping timeout: 240 seconds]
<slapin>
alsy: what is currently called GPU is vague thing, it can even be several devices i.e. 2D accel and 3D accel can be different peripherals but considered "GPU" entity by software
<slapin>
it looks like Pine64 android can't play video for some reason, but runs GTA SA quite well, so work will wait...
mosterta has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
scream has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
jernej has joined #linux-sunxi
alsy has quit [Ping timeout: 265 seconds]
solarnetone has quit [Read error: Connection reset by peer]
<agraf>
tuxillo: sure
paulk-collins has quit [Ping timeout: 240 seconds]
nemunaire has joined #linux-sunxi
<tuxillo>
agraf: I was wondering if it's possible to boot rpi3 in aarch64 mode with uboot and load a kernel image from tftp
<tuxillo>
i do that with my rpi2
<agraf>
tuxillo: sure! :)
<agraf>
tuxillo: should work just fine
<agraf>
tuxillo: depending on what you need and how sophisticated you need things to be, you can either use the built-in pxe support to load firmware+kernel blob (without u-boot), use built-in pxe support to load u-boot or put u-boot on the sd card / usb drive
<agraf>
tuxillo: once you have u-boot up, you can again either use the builtin extlinux.conf support or do pxe with efi grub2
<agraf>
tuxillo: or preconfigure an internal boot script that would manually load the files to ram and booti directly :)
<agraf>
tuxillo: so many possibiities!
Da_Coynul has joined #linux-sunxi
OverCR has quit [Quit: Leaving.]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
OverCR has joined #linux-sunxi
OverCR has quit [Client Quit]
<tuxillo>
agraf: thanks :)
<tuxillo>
agraf: but the support has been added recently?
<tuxillo>
agraf: I think it didn't work a few months ago in aarch64 mode. I want to do small baremetal programs and having u-boot to load the binary via tftp is very fast :)
<tuxillo>
agraf: wait, you said built-in pxe support. rpi3 has that?
ricardocrudo has quit [Remote host closed the connection]
solarnetone has joined #linux-sunxi
nemunaire has quit [Ping timeout: 264 seconds]
<vagrantc>
well, it kind of emulates pxe and supports pxelinux-style configuration files ... but it's a stretch to call it pxe
<willmore>
Also, they have the pi3 in AARCH64 mode? That's news to me.