<tuxd3v>
the dvfs, and temeprature and so on would be nice to run on it :)
<megi>
why?
Mangy_Dog has quit [Ping timeout: 240 seconds]
<tuxd3v>
its his purpose
<megi>
but why? :) if ARM CPUs run they can manage themselves
<tuxd3v>
I am thinking.. what should be the toolchain that suports it?
<megi>
if not, there's not muc heat
<megi>
gcc9 or1k
<tuxd3v>
gcc9 has this as a target?
<megi>
yes
<tuxd3v>
or is a specific version of gcc9?
<megi>
no, mainline
<tuxd3v>
nice
<megi>
it was added in 9.0
<tuxd3v>
I am wondering if ARM cross toolchains 9.x wouold support it :)
<megi>
no
<tuxd3v>
wouold -> would
<tuxd3v>
so we need to build first the cross tollchain for it..
<megi>
yes, or use a prebuilt one
<megi>
they're available on github
<megi>
I build it myself
ganbold has joined #linux-sunxi
<tuxd3v>
can we use that bynary blob with mainline kernels?
<tuxd3v>
I beliebe not?!
<megi>
no
ChriChri_ has joined #linux-sunxi
<tuxd3v>
does you know if something interesting was ported to 5.4.13 for H6?
<megi>
from when?
<tuxd3v>
i found a lot of things arm related but not for H6, unless maaybe for the stmac driver..
<tuxd3v>
since 5.4.12 :)
<tuxd3v>
or 11
ChriChri has quit [Ping timeout: 272 seconds]
ChriChri_ is now known as ChriChri
<megi>
no idea, random fixes :)
<megi>
I mostly follow just major version changes
NeuroScr_ has joined #linux-sunxi
NeuroScr has quit [Ping timeout: 272 seconds]
NeuroScr_ is now known as NeuroScr
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Ping timeout: 272 seconds]
TRS-80 has quit [Ping timeout: 265 seconds]
willmore has quit [Ping timeout: 260 seconds]
TRS-80 has joined #linux-sunxi
willmore has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<luke-jr>
is there a good SoC with wifi, 4x relays (or GPIOs to drive relays), a smallish/thin case + display available, AIOs, camera input, and the capability to decode 1080p in realtime?
<luke-jr>
SBC*
cnxsoft has quit [Remote host closed the connection]
<smaeul>
luke-jr: what specifically do you mean by decoding 1080p? from a camera? or h.264? or something else?
<luke-jr>
smaeul: ideally anything I could be expected to throw at mpv
<smaeul>
luke-jr: sure, but what is the source of the video -- network? CSI bus? storage?
<luke-jr>
it would be nice to sshfs-mount my NAS, but with a decent sized microSD I could preload I guess
NeuroScr has quit [Quit: NeuroScr]
<luke-jr>
is Cedrus working today? (my current projector system is a Novena which apparently never ended up getting its hardware acceleration working in the same kernel as HDMI audio..)
<smaeul>
I haven't personally used it. others may be able to tell you how well it works
<luke-jr>
ok, so Gentoo it is :P
cnxsoft has joined #linux-sunxi
<luke-jr>
hmm "Another lead is to use the Xv extension of the X11 API, that fits the bill for using the Display Engine hardware to accelerate these operations, but this interface is quite old now and increasingly deprecated. It also only allows sub-optimal use cases, with one video at a time."
<luke-jr>
didn't know Xv was deprecated, it seems to be the most reliable :x
<tuxd3v>
CONFIG_PHY_SUN9I_USB
<tuxd3v>
doesn't apply to H6 right?
<smaeul>
tuxd3v: nope, sun9i is A80 only
<tuxd3v>
smaeul, thanks :)
gaston1980 has quit [Quit: Konversation terminated!]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
NeuroScr has joined #linux-sunxi
megi has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has joined #linux-sunxi
aloo_shu has quit [Quit: WeeChat 2.5]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 265 seconds]
anarsoul|2 is now known as anarsoul
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 240 seconds]
selfbg has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder__ has quit [Ping timeout: 268 seconds]
fl_0 has quit [Quit: STRG + Q]
bjne has joined #linux-sunxi
fl_0 has joined #linux-sunxi
bjne has quit [Ping timeout: 272 seconds]
NeuroScr has quit [Quit: NeuroScr]
ldevulder_ is now known as ldevulder
montjoie has quit [Quit: leaving]
matthias_bgg has joined #linux-sunxi
tnovotny has joined #linux-sunxi
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-sunxi
hehopmajieh has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
bjne has joined #linux-sunxi
yann has quit [Ping timeout: 265 seconds]
TRS-80 has quit [Quit: WeeChat 2.3]
florian_kc has joined #linux-sunxi
florian_kc is now known as florian
AneoX has joined #linux-sunxi
yann has joined #linux-sunxi
montjoie has joined #linux-sunxi
Danct12__ has quit [Remote host closed the connection]
<maccraft123>
bbrezillon: what's the worst thing that could happen?
<maccraft123>
also
<maccraft123>
i paid for whole board
<maccraft123>
im gonna use whole board
<karlp>
wat?
<bbrezillon>
karlp: no, I meant those are usually not exposed on sunxi platforms, because they are MLC NANDs, and Linux does not support MLC yet
<KotCzarny>
lol
yann has quit [Ping timeout: 265 seconds]
<mru>
yet, haha
<karlp>
wasn't it more that it was removed?
<bbrezillon>
karlp: it's never been reliably supported
<karlp>
(I mean, I know it didn't _work_ welle nough)
<bbrezillon>
karlp: well, didn't work well is an euphemism
<maccraft123>
bbrezillon: is data loss the worst thing that could happen when im using mtd with mlc nand?
pmp-p has joined #linux-sunxi
<bbrezillon>
maccraft123: yes
<maccraft123>
ok
<maccraft123>
i'm in
<mru>
it probably won't be what causes trump to be re-elected
<mru>
but data loss is pretty much a given
<maccraft123>
something is on nand already
<mru>
look up "read disturb"
<mraynal>
bbrezillon: we know the OpenWRT community reverted the 'no MLC' patch right after we introduced it in Linux
<bbrezillon>
read disturb, write disturb and most importantly page pairing
<bbrezillon>
none of this is taken care of
<mru>
pairing only matters when writing
<mraynal>
maccraft123: you can play with it, but just because it seems to work, it does not mean it actually does
<maccraft123>
mraynal: around when it will be usable?
<mru>
if it has been written properly, you'll be able to read it a few times
<mru>
maybe even many times
<mraynal>
maccraft123: 5.7
<bbrezillon>
sure, if you use it as a RO FS, that should be okay
<mru>
as soon as the chips are no longer made
<maccraft123>
mraynal: okay
<mru>
then all gadgets will have the next type of storage which won't be supported
<mru>
until it has become obsolete
<mru>
etc
<mraynal>
maccraft123: I plan to merge the patches in nand/next at v5.6-rc1
<maccraft123>
i will be back
<bbrezillon>
maccraft123: you'll probably have to add some code for your NAND chip
<maccraft123>
mraynal: and it will work well enough to be able to not use sd card or hdd?
<mru>
mraynal: nice
<bbrezillon>
(page pairing description and read-retry implementation)
<mraynal>
bbrezillon: are you sure? writing blindly will not take into account pairing, so you'll probably corrupt your data very quickly
<bbrezillon>
mraynal: if blocks are entirely programmed, and never written again, that should work
<bbrezillon>
at least for some time
<mraynal>
ok
<bbrezillon>
then you have read disturb kicking in, and you're screwed
<karlp>
mraynal: so there's actually progress on mlc-nand now? that's good to hear.
<bbrezillon>
karlp, mru: it's just SLC emulation on top of MLC, so you'll end up with half the capacity
<mraynal>
karlp: I'm taking over bbrezillon's work
<bbrezillon>
but that's better than nothing
<mraynal>
indeed
paulk-leonov has quit [Excess Flood]
* karlp
sighs
<mru>
guess we'll keep using emmc then
paulk-leonov has joined #linux-sunxi
<mraynal>
paulk-leonov: quiting with an "excess flood" message while we are talking about MTD is not fair ;)
<mraynal>
mru: emmc means hidding the truth :) it does not serve exactly the same purpose
<KotCzarny>
or actually leaving the dirty work to controller's firmware
<mru>
emmc serves the purpose of shipping product
<KotCzarny>
and not screwing over it ourselves
<mraynal>
but for huge storages (compared to what an SLC NAND can provide), then yes, emmc is probably the way to go. and it is probably faster as chips are parallellized inside
<mraynal>
For those who have read at least once in their life manufacturer code, it's hard to trust firmwars
<mru>
well, right now the choice is between that and not being able to sell anything
<mru>
and I need to get paid somehow
TRS-80 has joined #linux-sunxi
<mraynal>
or using SLC if you don't need hundreds of MB. that's why I'm telling it does not serve the same purpose
<mru>
we do need hundreds of MB
<mraynal>
-> emmc
<mru>
good, we agree
<karlp>
what's the roadmap look like? is mcl/tlc nand _ever_ expected to be supported by linux or is this still a "no, not happening" worldview?
<mraynal>
tlc: I would say never, ever
<maccraft123>
qlc: no
<karlp>
so the roadmap remains "nand is an aberration, use emmc" then.
<mraynal>
mlc: not impossible, but very likely to never happen because 1/ bbrezillon works on other topics now and I don't have the background to take over plain MLC support and 2/ vendors do not share the pairing schemes
mauz555 has quit []
mauz555 has joined #linux-sunxi
maccraft123 has quit [Quit: oiuwqfeiufjoa;we]
maccraft123 has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
sunilmohan has quit [Ping timeout: 268 seconds]
sunilmohan has joined #linux-sunxi
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
pmp-p has quit [Ping timeout: 265 seconds]
ric96 has quit [Ping timeout: 265 seconds]
ccaione has quit [Read error: Connection reset by peer]