<libv>
i'm always amazed how much changes i need to make to the wiki whenever i try to use any of it
<libv>
especially now that we've been going all mainline
<libv>
seems like people cannot be bothered to actually have users.
<NiteHawk>
i'll have two, please :D
<libv>
who added the User: thing to the new device page howto?
<libv>
that statement right before it is not biased enough
* libv
is in two minds about it
<libv>
hah
<libv>
people who add a mainline u-boot category without adding a mainline uboot section should be shot.
<NiteHawk>
someone trimmed down the BPi page - "community kernel" is at 4.1 now??
<libv>
bpi has a community?
<libv>
which implies that it has only one community :p
<NiteHawk>
*sunxi* community, man :)
<libv>
:)
<libv>
you mean that actual community that all the $shitpi board vendors depend on :p
<NiteHawk>
seriously, i thought that linux-sunxi is 3.4-based and supposed to stay that way (just adding patches / backports on top of it)?
<libv>
NiteHawk: linux-sunxi has become way more than that
<NiteHawk>
i see
<libv>
NiteHawk: it's first and foremost a wiki and a ml these days
<libv>
people still almost exclusively depend on sunxi-tools and sunxi-mali
<libv>
the kernels and uboot have diverged
<libv>
especially since the people working the sunxi versions of those have spent their 2ys on it already and now have something else to do
<NiteHawk>
speaking of mali - now that gitorious.org is gone, is there a chance you might update the github one to the latest 'public' version of lima?
<libv>
yes, whenever i have done all the more important things that i am supposed to do
<libv>
right now i am setting up a lime to be able to tunnel (reverse ssh, through the proxy) into the VM on the windows PC inside the network of my customer, which has the most retarded and powerhungry it department ever seen
<NiteHawk>
:D
<libv>
i do not want that machine at my customer site to ssh into a machine i actually use or which has actual access to the rest of my network here
<libv>
i finally am fed up with the crap monitor/keyboard/mouse of that machine, and will be trading it for my own laptops setup, which sits 1m away and goes out on 3g, trading crap hw for latency.
cnxsoft has joined #linux-sunxi
<libv>
NiteHawk: where is this "community kernel" mentioned?
<libv>
our wiki looks halfway decent, although there is a lot of crap on that banana pi page
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<libv>
NiteHawk: and your remark is more aimed towards the use of the word community?
<NiteHawk>
yes. i think it's a mixup/confusion with the "mainline" setup (kernel + U-Boot), so referring to that as "community" struck me as odd
<libv>
indeed
<libv>
NiteHawk: fix it :)
<NiteHawk>
roger, wilco. :D
<libv>
you also might want to move the actual version info to the respective sections
<libv>
as in the gmac was added to mainline kernel 4.1
<NiteHawk>
even that is factually incorrect i think - gmac already worked fine on the last 3.18 kernel iirc
<libv>
did it not need some extra io poking?
<NiteHawk>
there was this GMAC_TX_DELAY mentioned in the wiki before (and now edited out :/), but i thought that was mainly related to the u-boot side of things...
<libv>
and that {{Note}} that was removed...
<libv>
that is still relevant
<libv>
the whole block is still relevant
<libv>
but should be moved to the manual build howto section
<libv>
which is quite the misnomber
<libv>
misnomer even
<libv>
these days at least
<NiteHawk>
yes. and gmac is also supported with 3.4 kernels - so it's not helpful to tell folks they need ML for that
<libv>
i, as no-one else probably will be arsed to do so, should go and split this across all device pages
<libv>
NiteHawk: did someone add this code to linux-sunxi/sunxi-uboot?
<NiteHawk>
oops, sorry - i might have confused that. I think gmac support is only present in lemaker's (github) fork of 3.4
<NiteHawk>
which is really what that note was all about...
<libv>
yeah, so reinstate that note in the manual build section :)
<libv>
the banana pi page is pretty noisy tbh, i can imagine it being pretty confusing for newcomers
<libv>
especially that whole variants section
<NiteHawk>
the whole bpi market/models/community mess *IS* confusing :P
<libv>
and i still need to finish the shitpi blog, which should put some things into perspective, after which we can see where we take the $shitpi denomination
marcin has joined #linux-sunxi
<libv>
the bpi is of course the shittiest of them all. that story is truly amazing
<libv>
but the orange pi is not much better, especially since it is now clear that they are shipping untested boards
<libv>
and then there's chip... where so much lies were spewed it's not funny. but they at least got shamed into using their massive amount of money for good these days
<libv>
but wait and see how long that will last.
<NiteHawk>
orange pi seems to a be half-scam with either failing hardware, or "bad by design" - looks like you're more or less unable to run those devices reliably
<libv>
cubie is also mentioned
<libv>
as "started nice, but now with tom gone..."
<libv>
even rpi is mentioned, due to their free graphics driver lie, and their kms driver still dependending on the VC RTOS binary, as booting still is today
* libv
is good at making friends
physis has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<libv>
hah, even the mainline kernel howto is badly structured and cannot be easily referenced to by the manual build howto.
<libv>
i am at least fixing up the manual build howto structure to fit the new reality
<libv>
also, mainline is a misnomer these days
<libv>
upstream is the proper name for it now
<libv>
sunxi vs upstream kernel/u-boot
<libv>
and there is not even a tiny bit of info about installing the dtb...
<libv>
that's seriously going to confuse average joe user.
linkmauve1 has joined #linux-sunxi
pekka30 has quit [Ping timeout: 268 seconds]
oliv3r has joined #linux-sunxi
<NiteHawk>
libv: well... if my memory serves me right, some time ago you reminded everyone to keep focus. sunxi isn't Wikipedia or Google and doesn't want to compete with them. getting joe avarage to do "linux from scratch" might be nice, but possibly out of scope?
<NiteHawk>
the point of sunxi is to deliver concise information if and where/how Allwinner SoCs are "out of the ordinary", and to detail the steps necessary to deal with that
<libv>
yes, but there is a difference copying wikipedia to explain what USB or UART is, and providing the few lines need to perform a kernel build and kernel installation
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
fredy has quit [Excess Flood]
<libv>
NiteHawk: nice catch :)
fredy has joined #linux-sunxi
<libv>
and good changes on the bpi as well :)
pekka30 has joined #linux-sunxi
<NiteHawk>
thx :)
<libv>
hrm, i am going to move the script.bin part of the manual build howto to the script.bin page
<libv>
oh wow, we really do have device tree file copies under u-boot?
<libv>
that'll definitely never go wrong!
<libv>
i am dropping the seperate mentions of the relevant howtos on the device page, people should refer to the manual build howto instead.
<NiteHawk>
it's probably best if we can establish some sort of "general procedure" covering most use cases (sunxi/legacy u-boot, sunxi, upstream u-boot, upstream kernela and u-boot), and mention everything that isn't accounted for or needs to be adapted on the specific device pages
<libv>
NiteHawk: this is what the manual build howto should be
<libv>
and something i did now for the building script.bin section to the script.bin page, is mention that people should get the name of the fex file from the device page
<libv>
i don't think we ever did the latter before
<NiteHawk>
yes, reorganizing that script.bin stuff sounds like a good idea to me
<libv>
it was necessary to reduce the superficial complexity of the manual build page
<libv>
and because that was the only bit that needed to be moved out of it for a long long time
<libv>
NiteHawk: nope, i think the linux kernel does not need dtc
<NiteHawk>
well... it sort of needs it, but comes with the dtc included - so that's a non-issue for the kernel
<libv>
i am actually not sure yet about what to do with the device tree page
<libv>
it is absolutely vital to have some of that info in the mainline/upstream kernel page
<libv>
and i really do think that with including device tree files in uboot directly, we have crossed a line we should not have crossed
<libv>
and we will be creating a lot of pain for ourselves now
<libv>
who is the canonical source of device tree files now?
<libv>
where does the documentation for device tree file structure and entries live?
<BroderTuck>
A bit of a mess overall having 1) preinstalled/sdk 3.4 kernel 2) linux-sunxi 3.4 that gets called deprecated 3) mainline and of course 4) the (used by ansolutely noone) allwinner github 3.4 stuff.
<libv>
there's a massive amount of pain ahead there (by not keeping kernel and uboot up to date or in sync, and the reason is not having thought things through and politics)
<NiteHawk>
strike 4 - no-one cares :D
<libv>
BroderTuck: yes, i know, but you still need linux-sunxi if you want full hardware support, or quick hw support for a newly NDHed device
<libv>
so there is a lot of history there which created this situation
Akagi201 has joined #linux-sunxi
<libv>
and... we have not always lived in a time where people actually considered upstream as the way to go
<libv>
linux-sunxi started at a time where we were really happy to finally have an android device which was not an across the board gpl violation
<libv>
that was only just over 3 years ago
<libv>
and we would never have even considered upstream if it was not for the luck we had with allwinner being that bad at IP control, and without linux-sunxi being formed off of that
<libv>
also, be glad that we have that wiki where we can create a bit of sense in this whole mess
<libv>
but then, people prefer to just complain about it, or run off in a certain direction without minding it, or both at the same time
<BroderTuck>
agree, 3) is still far from universally usable, that's why I addeed the quip about "gets called" 2). about 4, you'd think they would base newer sdk releases on it, but it doesn't really look like it.
<libv>
BroderTuck: i really dread having to call sunxi-3.4 legacy, but that's the reality of it
<libv>
and i would've personally kicked anyone elses ass who would've made that change to our wiki
<libv>
but it is what it is, sadly
<libv>
and i too have to own up to it now
<BroderTuck>
it is getting to be quite old by now, indeed.
<libv>
the 3.4 kernel?
<libv>
well, new devices seem to be created all the time and still depend on that kernel version
<libv>
if the chip had not been a success (for instance, by having been honest about the real cost of the device), and had not happened in the middle of the allwinner GPL shitstorm, it too would've shipped with the 3.4 ekrnel
avph has joined #linux-sunxi
<BroderTuck>
you'd certainly hope allwinner was a bit more interested in getting upstream support, but they and mainline went separate ways with things like fex and nand.
Akagi201 has quit [Ping timeout: 246 seconds]
<libv>
BroderTuck: taking my own experience with lima as an example, i can state that that is only hope
<libv>
and that no vendor does so on his own
<libv>
they have to be nastily and harshly forced.
<libv>
facts have to be created which make proper open source support the only option
<libv>
i am very good at creating such facts
<BroderTuck>
i'd certainly love to see proper open source support lima, kms and a v2l recedrus, but all those require skilled programmers with enough interest and time, and the amount of people with both seems to be zero.
<libv>
there is an inverse relationship between time and money
Gerwin_J has joined #linux-sunxi
avph has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
* BroderTuck
nods. if there was a kickstarter or something, I'd probably chip in, but i don't know if that's available for those of us outside the U.S.
<libv>
no, kickstarters are just noise machines, they only work in a very specific set of circumstances
<libv>
perfect for something like the chip, notsoperfect for more honest projects, definitely not useful for software projects
<libv>
free software projects, that is
<libv>
i am amazed that this still has to be said after all these years
avph has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 260 seconds]
avph has quit [Read error: Connection reset by peer]
avph_ has joined #linux-sunxi
avph_ is now known as avph
Gerwin_J has joined #linux-sunxi
<wens>
there's no wow factor
<libv>
then there's something else: the company i now work for uses the imx6q for its products
<libv>
they took the freescale because it was the cheapest
<libv>
they have been spending 1.5M per year on freescales "support", and wasted who knows how much in its own manpower
<libv>
my feeling currently is that 1/3rd of that was wasted on the vivante driver
<libv>
if that money had been spent on etnaviv, they would've had an amazing etnaviv driver by now, and then some
<libv>
and that's just one of the hundreds of stupid big companies out there
<libv>
pengutronix is the first company to actually have a third party pay for an open source arm gpu driver
<libv>
and they might get a second customer for it soon
<libv>
etnaviv started 3 years ago
<libv>
people and companies are very very stupid and wasteful
<libv>
and prefer to steal and in some cases lie, than to do the right thing from the start, or to own up to bad practices and save a lot of resources while getting a better product in the process
<libv>
and that usually boils down to individuals who are more occupied with keeping their own benefits (from a regular wage and a certain pension, to having a big title and a big car), than with getting things done, and getting things done well
<libv>
our manual build howto needs to be changed btw, to be relevant for all allwinner variants (which it could be)
<libv>
this is now almost true for upstream
<libv>
it is true for sunxi-3.4 which is for sun[457]i
<libv>
and it could be true for the other SoCs allwinner kernels as well
<libv>
and uboots of course
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 272 seconds]
MaDMaLKaV has quit [Read error: Connection reset by peer]
MaDMaLKaV has joined #linux-sunxi
valkyr1e has quit [Read error: Connection reset by peer]
valkyr1e has joined #linux-sunxi
valkyr1e has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<vpeter>
libv: What do you mean with "1.5M"? Euros?
<buZz>
i'd assume so, with him being european
<vpeter>
Would be nice to get little more explanation about whole story :)
<buZz>
about what?
<buZz>
money being spent on ducttaping proprietary solutions
ricardocrudo has joined #linux-sunxi
<buZz>
while same money would help FOSS reach perfection easily
<buZz>
this is not a story, its basic principle of capitalism
<vpeter>
My point exactly.
<buZz>
the more money you own, the worse your choices are :)
BroderTuck has quit [Quit: -]
<jelle>
does anyone know how to rescan the sdio bus?
<jelle>
the RDA5990 driver "seems" to be enabled via i2c and then it needs to recsan the sdio so I'm trying to do this in userspace
<buZz>
i thought SDIO wasnt a bus? just a single endpoint
<buZz>
not sure though
<jelle>
well yeah not sure if it's a bus either
<jelle>
buZz: just need to rescan it or let the driver do that
<jelle>
buZz: well I think it needs a the device in /sys/devices/ etc.
Akagi201 has quit [Ping timeout: 265 seconds]
lemonzest has quit [Quit: Leaving]
vishnup has quit [Remote host closed the connection]
Akagi201 has joined #linux-sunxi
Night-Shade has quit [Ping timeout: 252 seconds]
<jelle>
btw is anyone working on the rda5990/5991?
Akagi201 has quit [Ping timeout: 255 seconds]
domidumont has quit [Ping timeout: 246 seconds]
RSpliet has left #linux-sunxi [#linux-sunxi]
Gerwin_J has quit [Quit: Gerwin_J]
ricardocrudo has quit [Ping timeout: 268 seconds]
<libv>
vpeter: yes, eur, and yes, that's sadly how it works
atenart_ is now known as atenart
avph has quit [Ping timeout: 252 seconds]
Akagi201 has joined #linux-sunxi
pekka30 has quit [Ping timeout: 240 seconds]
Akagi201 has quit [Ping timeout: 264 seconds]
clonak has quit [Ping timeout: 272 seconds]
Turl_ has quit [Remote host closed the connection]
Turl has joined #linux-sunxi
clonak has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
paulk-collins has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
<libv>
hrm, i mix different machines and OSes and such too often to be allowed to use the wiki...
mpmctoo has joined #linux-sunxi
Igorpec8 has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
<mpmctoo>
Hi all, Anyone have any luck getting a newer kernel other than 3.4 running on an Allwinner H3 board? Yes I've looked at the Wiki but the build info is very limited, more specifically I'm looking for info on how to build a newer kernel for the Orange Pi PC, any help/info gratefully received!
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 244 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
pmattern has quit [Quit: Genug für heute.]
Night-Shade has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
mpmctoom: H3 it is not yet compatible with mainline, you need to use 3.x
<TheLinuxBug>
mpmctoo: H3 it is not yet compatible with mainline, you need to use 3.x